Conversion Importer (Importing Conversions from remote systems)

Owned by Siamak Haschemi (Deactivated)
Last updated: Dec 07, 2023
3 min read

Ingenious supports importing conversion from remote APIs using custom conversion importer. Importers are built on request by Ingenious.

What if you don’t have a importer to my system?

If you can’t find a specific data source importer? No worries! Reach our to your customer solution manager and describe your importer request. We will help you get your data into Ingenious. We often add new connections to data sources.

How long does it take to build a custom importer?

We respond to new custom importer requests within 2 business days, with the new data importer released 2 to 8 weeks from the initial request. The exact timing is dependent on the platform requirements and your validation of the output.

What are the requirements Ingenious has to build a custom importer?

In order to develop a importer to import conversions, your system needs to provide us a HTTP-based API (also sometimes called REST-API, or simply API). There are some requirements to your API, which can be divided in access, format, and request requirements:

Access

  • No IP whitelisting: The API should not restrict access to single IP addresses (also called IP whitelisting). Ingenious uses dynamic cloud environments with changing IP addresses.

  • Authentication: Your API should have an authentication mechanism (always a good idea). For the custom importer, you need to provide us a dedicated authentication independent from any real user-credentials. This isolation is important to troubleshoot problems with your development team, if needed.

  • Batch-Load: Ideally, we can load data for more than one day at the same time (called batching). This way, we can reduce the number of API calls to your system. We can agree with you on configration-specifics to not overload your system.

  • Rate Limiting: If your system implements rate-limiting, we need to know it’s behaviour, and how we can avoid reaching limits. If limits are configurable, we will agree with you on the config.

Format

  • Response format: The response format of your data should be one of the well-known formats (CSV, XML, JSON, EXCEL). However, we prefer structured responses using XML or JSON over unstructured, row-based data with CSV and EXCEL. If you have both options, we will use the structured version.

  • Data Formats: We need a description about

    • how monetary values are encoded, and which accuracy (number of digits before and after the comma) you have,

    • what time-format your API returns, and in which timezone,

    • what countries, currencies, and language codes you use

  • Schema: Every API has specific data which is returned. We need a description of the data-schema your API will return. Ideally, this schema is based on OpenAPI, json-schema, or another well-defined schema language.

  • Error-Codes: API calls can fail based on various reasons. We need to know how your API behaves in case of problems, in order to react correctly in the custom importer.

Requesting Data

  • Time-Based or Offset-Based Request Pattern:

    • Most APIs allow time-based access where we can specify a time-period to load data.

    • However, some APIs also allow an offset-based request, where each data returned is associated with a offset-id. Offsets are ordered Integers/Longs, which bring data in order. In those APIs, we can ask the API to give us new data by sending the offset with the request. Any data newer than the offset is returned.

    • We need to know what request pattern your API has.

  • Append-Only (nice to have): Ideally, your data is append-only. This means, that no historic data is changed, and all changes are made going forward. Some systems a call this approach “event based”, where each event describes a change at a specific time.

  • Late arrivals: If your API is not based on events, and your data also changes historically, we need to know a limitation time-frame how long changes can happen for past objects. For example, if yo allow data to change until 30 days in the past, we support this.

iGaming Data Models

When your business model is from iGaming, we will require you to help us mapping your data to our unified iGaming data model. We have two models where columns are prepared for you to map your data.

Please look at this Spreadsheet for further details: https://docs.google.com/spreadsheets/d/1UaKHjVxgsJw5w4TCZOYlvsQamEYxSpiVZ0GlFdwPW24/edit?usp=sharing