Integration Steps

The following steps outline the proposed order and dependencies of the integration. Some steps can be completed in parallel:

1. Agree on the integrationId. This is typically based on the name of the client company (casino operator or game provider/aggregator) or the main group of users who will manage the tool.

2. Provide Gamity with at least one operator and one brand name that will be used for testing during the integration. These names should come from the client’s system.
   For operators with only a few brands, these can be recorded manually by Codemodity.
   For game providers and aggregators, it is recommended to use the Sync Operators and Brands API to sync multiple operators and brands at once, especially in a production environment. In production, the sync call should run once per day so that operators and brands remain reasonably up to date.

3. Sync games with Gamity. Gamity needs a list of games available for the different operators and brands, as tournaments can only be created for these games. During testing, a few agreed-upon games can be added manually by Codemodity. It is recommended to use the Sync Games API to synchronize games between the systems, especially in production. This sync can run once per day, or more frequently if the game lists change often.

4. Agree on the method used to share game rounds or transactions (e.g. RabbitMQ, Kafka, HTTP API, etc.). Based on the selected approach, implement the integration accordingly.

5. Integrate the In-game UI Widget, ideally first in test mode and then using a properly parameterized JWT.

6. Optionally integrate the Lobby UI.

   • For operators, this is straightforward, as all parts of the integration are handled by the same entity.
   • For game providers and aggregators — where game transactions/rounds and the in-game UI widget are supplied to operators, but the provider/aggregator does not control the operators’ sites — the operators themselves need to integrate the lobby. They must ensure that all data (integrationId, brandIds, and gameIds) matches what is used by the provider/aggregator.

7. If there is a large user base and a high volume of transactions, it is recommended that the Active Games API endpoint be used to:

   • Filter relevant transactions sent to Gamity, thereby reducing the amount of data that needs to be transmitted between the systems.
   • Optionally control which games should load the in-game UI widget (the widget itself also handles this, but this provides an additional optimization).

   This endpoint should be called every 3 minutes so new tournaments are picked up in a timely manner.

8. Implement the Payouts API for processing tournament payouts.

9. Implement the Debits API for processing debits for tournament buy-ins and entry fees.

In a QA/staging environment, a test casino site must be provided to Codemodity, along with test user credentials, to enable end-to-end testing of the integration.