Workflow

Overview

Communication between Platform (Partner, Game Aggregator) and Provider:

• Platform API for Provider - describes requests from Provider to Platform.
• Provider API for Platform - describes requests from Platform to Provider.

Game flow

Opening a game

1. Player opens a game page.
2. The Platform sends a /game/init or /game/demo request to the Provider.
3. The Provider responds with a game url to the Platform.
4. The Platform uses the game url to open the game in an iframe.
5. The player starts playing.

Game process

1. An event occurs in the game (such as getting the balance, betting or winning).
2. The Provider sends a corresponding request (/balance, /bet, /win) to the Platform.
3. The Platform handles the event and responds to the Provider.
4. The player continues to play.

Failed request cases are described in the Error handling section and can be found in a workflow diagram below.

Workflow diagram

Freespins flow

Freespins implementation is not required for the basic integration — the core platform functionality can operate without Freespins API support.

Notice

If the Platform decides to implement the API and its freespins setup requires /bet/win per-spin requests, the Platform should notify its integration engineer in advance.

The integration engineer will apply required settings for the Platform.

The implementation of freespins involves two main entities: a freespin campaign and freespins. Within a single freespin campaign, a Player can receive only one set of freespins.

A freespin campaign is a general promotion that a Platform can create. Based on its parameters, Players will be awarded freespins.

Freespins are complimentary spins that are credited to Players when they enter the game.

Creating a campaign

1. The Platform rewards the Player with bonus freespins by creating a freespin campaign via the Platform's user interface (or by passing the request from the Casino).

Notice

When creating a campaign, the Platform should ensure it sets a valid betLevel parameter. Available bet levels can be retrieved via the /bet-levels endpoint.

2. The Platform sends a /freespins/create request to the Provider.
3. The Provider confirms the successful issuance of the freespin campaign.

Canceling a campaign

Campaign cancellation also cancels and closes all current freespins. Its use is not recommended if any players have already received them.

1. The Platform cancels a freespin campaign via the Platform's user interface (or passing the request from Casino).
2. The Platform sends a /freespins/cancel request to the Provider.
3. The Provider confirms the successful cancellation of the freespin campaign.

Game process

Notice

The Provider sends only one /finish request to the Platform per freespin bonus game. The Provider doesn't send /bet and /win each spin.

If the Platform uses a /bet/win per-spin setup, the Provider sends /bet and /win requests for each spin and does not send /finish request at all.

1. Player enters the game.
2. The system checks if the player matches the freespin campaign conditions (currency, game, or specific player identifier).
   • If the player qualifies, they receives the freespins.
   • Otherwise, the usual game flow starts.

The freespins bonus game is not related to the Player's actual balance. Instead, the Player sees the number of freespins that have been issued.

3. As the Player makes a spin, the number of freespins decreases.
4. The amount of winnings is calculated and accumulated on the Provider's side.
   • If maxWin parameter is provided, the system checks if the total amount is still within the limit.
   • If maxWin is reached, the Provider ends a freespin bonus game and sends a /finish (or last /win) request with the maxWin amount.
5. When all the freespins have been played, the Provider sends a /finish request to the Platform with the total winnings.
   • If the minWin parameter is provided and total win is lower, the Provider sends a /finish (or last /win) request with the minWin amount.

Failed request cases are described in the Error handling section and can be found in a Game flow diagram.

Workflow diagram

Error handling

1. An event occurs in the game (such as getting the balance, betting, winning or finishing the freespin rounds).
2. The Provider sends a corresponding request (/balance, /bet, /win or /finish) to the Platform.
3. The Platform responds to the Provider with an error.
4. The Provider shows an error to the player.
5. If it was a /bet request (the one from point 2), the Provider sends a /refund request (if the error is not PlayerLowBalance).
6. If it was a /win or /finish request, the Provider retries the request.
7. If it was a /refund request and the error is not BetNotFound, the Provider retries the request.

Default values

Request timeout to the Platform is not limited.

Step intervals to redo (retry) a request in seconds:
[8, 32, 64, 256, 1024, 4096, 16384, 65536]