IGaming Non-Restrictive Integration Toolkit Ecosystem
1. Document change history
Table 1. Document change history
28.2.2024
0.1
Initial Version
23.5.2024
0.2
Added 4.5 Navigation
1.12.2024
0.3
Added 4.5.3 onDomEvent
24.2.2025
0.9
Casino integrations, revamped structure.
15.07.2025
1.0
12.
Cryptocurrencies list.
24.10.2025
1.1
8.
content and gameId added to RollbackRequest
2. Introduction
iGNITE (iGaming Non-restrictive Integration Toolkit Ecosystem) is a set of tools and systems enabling the standardized integration of Sportradar's game portfolio.
This document is designed for B2B partners (Operators, PAMs, iGaming Platforms) who wish to integrate content aggregated by Sportradar's NextGen iGaming Platform.
This includes the following content:
Table 2. Content
Sportsbook
Sportradar
VirtualGames
Sportradar
Casino
Sportradar, Betgames.tv
2.1. Glossary
Table 3. Glossary
Operator
Entity/System/Company that offers iGaming content to the users.
Operator FE App
Application owned by operator, which integrates game content. Web application, mobile application, etc…
Game UI/Game iFrame
Game frontend, e.g. Sportsbook UI, Virtual Game UI, Casino UI
iGNITE Core
Part of Sportradar's NextGen iGaming Platform that is in charge of managing punter accounts and betting transactions
Operators Platform / PAM
Single or multiple systems in charge of handling user sessions and betting transaction flow on Operators end
3. Integration overview
There are three integration concepts between operators and Sportradar's NextGen iGaming Platform.
Game UI integration (Frontend integration)
The standard integration method is to embed the game iframe in the operator’s frontend application.
Alternatively, for the original products, the operator has the option to implement each game's frontend based on its respective API (covered in a different document. Please talk to your Client Success Manager).
Punter Session integration
Enables seamless session management between operators' and Sportradar systems.
Bet Acceptance integration
Operators are contacted for every relevant betting action (DEBIT, CREDIT, ROLLBACK).
Bet acceptance integration can be configured in two modes:
BASIC: Only basic wallet transaction data is shared between systems for systems that do not want to consume detailed bet data.
RICH_CONTENT : Basic wallet transaction data is expanded with in-depth details from each bet that occurred within the system.
For RICH_CONTENT mode, there is also the option of integrating a special Auxiliary API that enables operators to consume data beyond DEBIT, CREDIT & ROLLBACK actions. E.g., track status changes for each bet selection, or to consume lost bets, etc.
Since RICH_CONTENT mode provides bet identifiers rather than sending full localized data of each bet or round parameter, content beyond IDs can be shared with operators via specially designed pull (KAFKA) and push (HTTP) APIs.
Technically, high-level integration covers:
Frontend integration: (chapters 4, 5)
UI integration via Chatty iFrame or Simple URL launcher
Backend integration: (chapters 6+)
Connection between Sportradar's iGNITE Core and Operator Platform.
Integration of all concepts is HIGHLY recommended.
For seamless types of integration, the following subsequent chapters are key:
Additionally, core subsequent chapters for Casino content integrations are of value:
Core subsequent chapters for Betslip content integrations are of value:
For the transfer wallet type of integration following chapters are key:
4. Game UI integration (Frontend integration)
Depending on the type of content being integrated, UI integration can be done in two ways:
Simple URL Launcher: Typically used for casino content where, after loading the game, there is little to no interaction between Operators Front End and Game Content. The game is loaded via URL, and after that, there is no interaction between the two frontends.
Chatty iFrame: Typically used for sportsbook and virtual games scenarios that allow more interactivity between Operators Front End and Game Content. Offers a system of JavaScript events and messages that are constantly exchanged between the two frontends.
In practice, the difference between the two approaches is subtle. Chatty iFrame provides the Operator FE App with more control (for content that supports it).
Simple URL Launcher:
Chatty iFrame:
4.1. Simple URL Launcher
Game content is loaded by using the game URL when a session for a specific game starts. After that, everything is delegated to the backend integration.
Along with the base URL, the following URL parameters are required for each game load:
x__token: Punter’s session token
x__externalId: Punter’s unique identifier in the operator’s system
x__linkId: Provided at integration, different for each game
x__gameId: Provided at integration, different for each game
x__tenantId: Provided at integration
x__activeCurrency: ISO 4217 currency code
x__activeLocale: ISO 639-1 alpha-2 language code
x__playMode:
[REAL, DEMO]
4.2. Chatty iFrame
The central piece of integration is the JavaScript SDK iGNITE.js, designed to act as a standardized communication bridge between Operator FE App and various Game iFrames.
4.2.1. iGNITE.js Overview
iGNITE.js is a JavaScript SDK designed to act as a standardized communication bridge between Operator FE App and various Game iFrames. The SDK comes in two modes:
Parent: To be used by Operator FE App in order to feed necessary data to games.
Child: To be used by Game iFrame to communicate with Operator FE App.
4.2.2 Prerequisites
At the integration start, the operator will get the following details to be used through the integration process:
4.2.2.1 sdkParentUrl
Endpoint from which the iGNITE.js SDK should be loaded.
4.2.2.2. tenantId
A unique identifier representing the tenant within Sportradar systems. The tenant is the boundary that separates one operator from another.
On special occasions, a single operator may operate under multiple tenants for various reasons (e.g., different user pools, different platforms across countries).
4.2.2.3. gameId
A unique identifier representing the game within Sportradar systems.
4.2.2.4. gameUrl
URL to load game HTML <iframe> . Each gameId has its own gameUrl.
4.2.2.5. env
Represents the integration environment. One of:
staging: Used for the pre-production stage and testing.
production: Used for production.
4.2.3. iFrame Integration
4.2.3.1 SDK Injection to Index File
Inject <script> element into your index file:
It is highly recommended to initialize iGNITE.js SDK early on the homepage or as part of the game lobby, long before the punter navigates to the integrated game page. Certain products have various punter-based customization benefits and will have faster loading times if they can acquire punter details early.
4.2.3.2. Integrator Parent Creation
After the script is loaded, the global variable igniteIntegrator becomes available, and it is used to initialize the integrator. The integrator must be initialized before the iframe source is set. It should be done in the following manner:
tenantId - (UUID) Unique tenant identifier. Provided at integration start.
externalId - (string[100]) Unique punter identifier in the Operator's system
feToken - (string[1000]) Session token in the Operator's system
env - staging vs production
debug - (de)activates different debug features (like logs, etc.). Always true on staging env
settings - object containing settings that will be used in all child nodes
activeCurrency - object containing details regarding the currency used. Available currencies must be exchanged before integration starts
code - ISO 4217 currency code
symbol - Currency symbol to be displayed
activeLocale - ISO 639-1 alpha-2 language code
oddsOption - oneOf: DECIMAL, FRACTIONAL, AMERICAN
manualWalletsUpdate - (boolean)[optional] - Refresh balance in frame
b2bVal - [optional] (string[1000]) Value to propagate on every punter-initiated action from Operator FE App to Operator Platform
children - collection of objects that represent integrated games, with parameters:
frameId - Unique frame identifier assigned by Operator
childId - Parameter assigned at integration start for each game integration.
gameOptions - [optional] Object reserved for propagating options specific to each game to the specific Game iFrame. Possible options are communicated at integration start (if available)
b2bVal - [optional] (string[1000]) Value to propagate on every punter-initiated action from Operator FE App to Operator Platform. Has precedence over the global value set in the root settings node.
events - [optional] object containing a list of event handlers
onNavigationChanged - [optional] (function) Event handler that gets triggered when in-product navigation occurs, e.g., navigation to tournament/match details in the case of a sport product. See navigation
onNavigationRequested - [optional] (function) Event handler that gets triggered when external navigation is requested from a child, e.g., browser history actions back/forward, external site navigation. See navigation
onLoginRequested - [optional](function) Event handler that gets triggered when a user attempts to do an action for which they need to be logged in
onBalanceChanged - [optional](function) Event handler that gets triggered when a child detects there has been a change in active currency balance (e.g., after a bet is placed). This only works when manualWalletsUpdate is set to true
4.2.3.3. Iframe setup
For each integrated game, the operator must set the iframe element source to the provided gameUrl for the appropriate product.
iframe id must be unique since it represents the basis of communication between iGNITE.js parent and children.
4.2.4. Message exchange between parent and iframe child
4.2.4.1. setSession / destroySession
See Punter Session Integration (Chatty iFrame) for in-depth details.
4.2.4.2. updateWallets
Game iFrame must be aware of the punter’s balance in order to facilitate bet placement. Game iFrame will regularly collect this data from the backend via iGNITE Core, but for an optimal experience, additional frontend implementation is required.
id* - (string[100]) Wallet identifier. If not available in the Operator system, any random string value should be set.
type - (oneOf: REAL, BONUS) Differentiates between real and bonus money wallets.
balance - (string) See Amount
currency - (string) See Currency
version - Balance version. If unavailable, set the UNIX timestamp when the request was generated. This value handles race conditions between frontend and backend balances.
options - Node reserved for special bonus scenarios (Out of scope of this document).
4.2.4.3. updateSettings
Ability to update any settings set while the SDK parent is initialized (Integrator Parent Creation).
4.2.4.4. updateGameOptions
Ability to update any gameOptions set while the SDK parent is initialized (Integrator Parent Creation).
4.2.4.5. navigateBack/Forward
Notify child(ren) about navigation through history on the Operator’s app that should be reflected inside the child as well. E.g., the user navigates with the browser back action from event details to a full offer.
4.2.4.6. navigationChanged
Notify a child about navigation in the Operator’s app that should be reflected inside the child as well. E.g., user navigates to live sport offer.
4.2.4.7. sendMessage
When there is a need for a specific message to be sent to a specific child (or all of them, if childId is omitted), the following can be used:
Action and data structure will be agreed upon on a case-by-case basis, depending on what needs to be communicated.
4.2.5. Events
4.2.5.1. onNavigationChanged
This handler enables the Operator’s URL updating and preserving a certain product view after a page reload. It will be triggered every time navigation occurs in the child app. It receives a data parameter that looks like the following:
path - (string(1000)) Represents the pathname part of the child app.
params - [optional] Object containing product-dependent data.
Use-case:
A player navigates to a specific tournament view inside the sports child application. The Operator’s application uses the provided path and updates its own URL. On page reload, the same path should be used as a pathname for gameUrl in order to activate the same tournament view:
4.2.5.2. onNavigationRequested
This handler is used when external navigation is required. It receives a data parameter that looks like the following:
type - (oneOf: GO, BACK, FORWARD) Represent request type of the navigation. GO is used for external URLs, e.g. marketing banners get clicked and the operator’s page should redirect to a certain URL or open it in a new tab. BACK and FORWARD are used when simple browser history navigation is requested.
data - [optional] Contains additional information when navigation type GO is used.
url - (string) URL that is requested to be opened.
target - (oneOf:
_blank) If provided, it will have the value_blank, indicating that the URL should be opened in a new tab.
4.2.5.3. onDomEvent
This handler is used when there’s a need to listen to certain DOM events happening in the child. It receives a data parameter that looks like the following:
type - represents the name of the DOM event that occurred.
params - different sets of data that additionally describe the DOM event. The structure is entirely dependent on the event in question. The example above shows what will be sent for the scroll event.
5. Punter Session Integration (Chatty iFrame)
Backend integration is identical in all use cases.
In order to place bets, punters must be authenticated to the iGNITE Core.
iGNITE Core supports on-the-fly punter registration and authentication.
Session identifiers are propagated from the Operator FE App via iGNITE.js SDK.
Steps necessary from operators POV:
Operator FE App invokes setSession via iGNITE.js SDK
setSession method is used for both the initial session and for any session changes. Each session change within the Operator system should trigger setSession invocation with a fresh _feToken_set.
feToken represents a token that is generated by the Operator FE App. It will be validated by the operator and exchanged for sessionToken which will be used for all backend actions. Operators are free to use the same value for both feToken and sessionToken.
2. iGNITE Core invokes SessionCheckRequest. Operator Platform is expected to validate if the feToken matches the one issued to the Operator FE App. Operator Platform is expected to return sessionToken (can be the same or a different value as feToken)
Please refer to Punter Session Integration (backend) for in-depth API details.
3. The operator can trigger a logout action by invoking the destroySession method.
6. iGNITE Core (Backend Integration)
6.1. Overview
All backend APIs follow the same principle. Requests are generated on iGNITE Core, and the Operator needs to build a service that responds to these requests in a documented fashion.
In-depth details of the integration will be described in Punter Session Integration(backend) chapter and onwards.
Within this chapter, we’ll mention general guidelines and requirements.
6.2. API Integration URLs
The operator platform must provide a URL when integration is ready for testing:
SessionCheck (POST)
SessionRefresh (POST)
FetchPunterDetails (POST)
Debit (POST)
Credit (POST)
Rollback (POST)
FetchWallets (POST)
Details of each method are described in Chapter 7 and onwards.
6.3. API - API authentication
The operator platform is expected to protect integration URLs with Basic HTTP authentication.
6.4. HTTP Headers
Standard HTTP headers will be generated on each request.
6.5. Respond with HTTP 200/OK only
The Operator platform is expected to respond with an HTTP 200/OK response as documented.
6.6. Performance requirements
The operator must ensure that the total response time between iGNITE Core and _Operator Platform_is below 200ms and must be below 400ms at all times. This includes network latency between systems.
6.7. Idempotency
All methods must be implemented as idempotent (repeat safe) by the Operator Platform.
The operator must return an identical response to any retried transaction as it would have been returned by the first call.
A retry can take place several seconds, minutes, hours, or days after the initial try.
6.8. Security
If not agreed otherwise, the operator must provide SSL/TLS URLs for all backend endpoints.
6.9. Session Validation
When received, the original sessionToken propagated from the Operator FE App must be validated by the Operator Platform.
6.10. Backwards compatibility
New features and functionality will constantly be added to iGNITE Core, which can lead to the addition of new parameters not included in this documentation.
Operator Platform must ignore, without failure, the presence of new or additional non-documented parameters.
7. Punter Session Integration (backend)
Chapter Punter Session Integration (frontend) describes the authentication flow that starts in the Operator FE App and concludes with operator session validation on the backend via the Operator Platform. Please refer to it for a larger context.
The Operator Platform is expected to respond to the following HTTP requests triggered by the iGNITE Core.
Name
Description
SessionCheck
Validates punter session
SessionRefresh
Refresh punter session
PunterDetails
Retrieves punter details
7.1. SessionCheck (POST)
Operator Platform validates if the feToken matches the one being propagated by the Game iFrame.
Table 4. SessionCheckRequest
feToken
string(1000)
Session token propagated by frontend application
This value can be the same as sessionToken to be returned if the operator uses the same session id for frontend and backend.
externalId
string(100)
Punter identifier in operator’s system
tenantId
UUID
Tenant identifier agreed on integration start
clientUserAgent
string(1000)
User-agent used by the punter
*Optional
Table 5. SessionCheckResponse
isValid
boolean
true/false. Does feToken value match the one provided to the Operator FE App?
sessionToken
string(1000)
Session Token to be used in Betting Acceptance Integration.
This value can be the same as feToken if the operator uses the same session id for frontend and backend.
clientError- Message*
string(1000)
Error message to be presented to Punter in case of isValid:false. Applicable to selected providers.
7.2. SessionRefresh (POST)
Operator Platform generates a valid SessionToken.
Table 6. SessionRefreshRequest
SessionToken
string(1000)
Session token to be used in Betting Acceptance Integration
This value can be the same as feToken if the operator uses the same session id for frontend and backend.
externalId
string(100)
Punter identifier in operator’s system
tenantId
UUID
Tenant identifier agreed on integration start
clientUserAgent
string(1000)
User-agent used by the punter
*Optional
Table 7. SessionRefreshResponse
isValid
boolean
true/false. Does sessionToken value match the one provided to the Operator FE App?
sessionToken
string(1000)
Newly generated Session Token
clientError- Message*
string(1000)
Error message to be presented to Punter in case of isValid:false. Applicable on selected providers.
*Optional
7.3. FetchPunterDetails (POST)
Game iFrame and returns information regarding the punter.
Table 8. PunterDetailsRequest
feToken*
string(1000)
Session token propagated by frontend application
externalId
string(100)
Punter identifier in operator’s system
tenantId
UUID
Tenant identifier agreed on integration start
clientUserAgent*
string(1000)
User-agent used by the punter
*Optional
Table 9. PunterDetailsResponse
type
enum
oneOf:
PLAYER: Online player
externalId
string(1000)
Punter identifier in Operator Platform
nickname
string(200)
Nickname
brandId*
string(32)
Brand identifier in Operator Platform
agentId*
string(32)
Agent identifier in Operator Platform
affiliateId*
string(32)
Affiliate identifier in Operator Platform
dob*
date
Date of birth
email*
string(200)
personal- Number*
string(200)
Personal number provided by jurisdiction.
sex*
enum
One of:
M: Male
F: Female
firstName*
string(200)
First name
lastName*
string(200)
Last name
mobileNum*
string(200)
Mobile number
resAddress*
string(200)
Residential Address
resCity*
string(200)
Residential City
resPostal- Code*
string(200)
Residential Postal Code
resCountry*
string(200)
Country of residence
taxCategory*
string(200)
Tax Category
taxRegion*
string(200)
Tax Region
rcPeriod*
Integer
Realty check period (in minutes)
Parameter
Type
Description
isTesting*
boolean
Marks test user
tags*
Tags
List of Tags assigned to a Punter. See table 10 below
*Optional
Table 10. Tags
tagCode
string(1000)
Tag Code.
tagName
string(1000)
Tag Name.
8. Bet Acceptance BASIC Integration
BASIC bet acceptance integration is the foundation of Bet Acceptance and is enough for Operators that do not require in-depth bet information consumption.
Integration is done via 4 HTTP endpoints:
Debit
Debit (takes funds) from punters wallet/balance
Credit
Credit (award funds) to punters wallet/balance
Rollback
Rollback of debit or credit transaction
FetchWallets
Retrieves punter wallets and balances
8.1. Debit & Credit (POST)
Both DEBIT & CREDIT must be implemented as idempotent (repeat-safe) (read more HERE).
CREDIT call must respond with status OK, and will be repeated until an OK status is received.
Table 11. DebitRequest / CreditRequest
Id
ULID
Unique transaction identifier
tenantId
UUID
Tenant identifier agreed on integration start
gameId
integer
Unique Game identifier defined on integration start
contentType
enum
One of:
BETSLIP: Betslip based games (e.g., Casino, Virtuals)
CASINO: Casino games
content*
RichContent
Non-null if RICH_CONTENT mode is activated.
b2bVal*
string(1000)
Value propagated from Operator FE App
*Optional
Table 12. DebitResponse / CreditResponse
errorMessage*
string(1000)
Error message in case of NON-OK status
clientError- Message*
string(1000)
Error message to be presented to Punter in case of NON-OK status.
*Optional
8.2. Rollback (POST)
Must be implemented as idempotent (repeat-safe) (read more HERE).
Must respond with status OK, and will be repeated until an OK status is received.
Rollback is used to reverse any Debit or Credit request.
In case of Rollback of Credit, funds should be taken from punters (Operators reserve the right not to do so, but still have to respond with status request OK)
In case of Rollback of Debit, funds should be given to the punters
Table 13. RollbackRequest
id
ULID
Unique transaction identifier
tenantId
UUID
Tenant identifier defined on integration start
gameId
integer
Unique Game identifier defined on integration start
contentType
enum
One of:
BETSLIP: Betslip based games (e.g., Casino, Virtuals)
CASINO: Casino games
content*
RichContent
Non-null if RICH_CONTENT mode is activated.
*Optional
Table 14. RollbackResponse
errorMessage*
string(1000)
Error message in case of NON-OK status
*Optional
8.3. FetchWallets (POST)
Used to retrieve the state of punter wallets/balances.
Table 15. FetchWalletsRequest
tenantId
UUID
Tenant identifier defined on integration start
*Optional
Table 16. FetchWalletsResponse
errorMessage*
string(1000)
Error message in case of NON-OK status
*Optional
9. Betslip RICH_CONTENT Integration
Betslip type games include Sportsbook, Virtual, and Lottery games
Rich content integration is designed for operators that require more than basic betting details. If this is not the case BASIC integration should suffice.
9.1. What is a Betslip?
A betslip represents a collection of Bets.
Betslip is only a container for bets, so it is unaware of data such as stake or payout amounts and is not subject to tax regulations. This data is part of each bet.
Each betslip has its own identifier.
Most betslips placed will be betslips with one bet only. But multi-bet scenarios are present in a variety of sportsbooks and virtual games scenarios.
9.2. What is a Bet?
A bet represents a set of selections and their predicted outcome
A bet is always a part of the betslip container.
Bets on the same betslip are independent of each other, which means that their life cycle can be in different phases.
9.3. What is a Selection?
A selection is part of a bet.
A selection is associated with the market and outcome that punters try to predict.
9.4. Systems bets (selectedSystems)
System Bet is a mixture of several accumulator bets that make it possible to lose one or more bets and still win part of the bet. All bets are communicated as systems bets. selectedSystems node gives context to the bet.
The Bet above is made of 8 selections.
By altering selectedSystems nodes, these bets become different accumulators. E.g.:
[8]
1
1 Eightfold accumulator bet
[7]
8
8 Sevenfolds accumulator bets
[6]
28
28 Sixfolds accumulator bets
[5]
56
56 Fivefolds accumulator bets
[1]
8
8 Single bets
[2,3,4,5,6,7,8]
247
“Goliath'' made up of 247 bets. 28 Doubles, 56 Trebles, 70 Fourfolds, 56 Fivefolds, 28 Sixfolds, 8 Sevenfolds and one Eightfold.
9.5. Selection Category
Each selection is placed into a certain category. categoryId is represented by a single string and using the formula:
categoryId = “cat_lvl_1” + “/” + “cat_lvl_2” + “/” + “cat_lvl_3” + “/” + "cat_lvl_4"
Where each integrated game/product has its own category hierarchy.
E.g., Sportradar's Sportsbook uses the following logic:
cat_level_1 = live vs prematch identifier
cat_level_2 = {sport ID} (e.g., Soccer, Basketball)
cat_level_3 = {subcategory ID} (e.g., England, Finland, International, International clubs )
cat_level_4 = {tournament ID} (e.g., Premier League, World Cup, FA Cup )
9.6. Bet Activity
Bet activity adds additional context to the basic CREDIT, DEBIT, and ROLLBACK methods' basic payloads.
Operators can utilize this data to get information about every detail of every bet placed.
activityId serves as an index to go down further inside bet details.
A simplified JSON example can be found below:
A sequence diagram depicting different bet activities can be found below:
An in-depth overview of each activity can be found in the chapters below.
9.6.1. Betslip Placement (PREPARE_PLACE_BETSLIP)
Expected Operator Platform Behavior: DEBIT (remove) funds from punters wallet(s).
9.6.2. Part of bets are rejected (CONFIRM_PLACE_BETSLIP)
This activity is optional, and a request will be triggered only in scenarios where at least one of the bets from the betslip is rejected.
Expected Operator Platform Behavior: CREDIT (add) funds to punters' wallet(s), in order to compensate funds taken during PREPARE_PLACE_BETSLIP action.
9.6.3. Cashout (CASHOUT_BETS)
The Cashout functionality enables punters to get money back on their bet at any time during the event they’ve bet on, not just when the event is over. This is most common, but not exclusive to, sportsbook betting games.
This activity is optional and the request will be triggered only in scenarios where at least one of the bets from the betslip is cashed out.
Expected Operator Platform Behavior: CREDIT (add) funds to punters' wallet(s).
9.6.4. Bet Cancellation (CANCEL_BETS)
This activity is optional and the request will be triggered only in scenarios where at least one of the bets from the betslip is canceled, either by the punter (for games that support this functionality) or by the game provider.
Expected Operator Platform Behavior: CREDIT (add) funds to punters' wallet(s), compensating for the cancellation.
9.6.5. Bet Payout (PAYOUT_BETS)
This activity is optional and the request will be triggered only in scenarios where at least one of the bets from the betslip is winning.
Expected Operator Platform Behavior: CREDIT (add) funds to punters' wallet(s).
9.6.6. Bet Resettle (RESETTLE_BETS)
There are rare instances where certain game providers support “recalculation” for bets. This may occur after an incorrect sports or lottery draw result is reported or due to a punter complaint, etc.
This activity is optional and the request will be triggered only in scenarios where at least one of the bets from the betslip has to be resettled.
Expected Operator Platform Behavior: Depending on the method received, the operator needs to CREDIT (add) or DEBIT (remove) funds from/to punters' wallet(s).
If the Operator Platform does not support DEBIT (removal) of funds from punters' wallets after they have already been awarded, or cannot process these requests because the punter’s balance would go negative, the Operator Platform reserves the right not to process these requests internally. Regardless of what has been done on the Operator Platform end, it is mandatory that the response generated from the operator is successful.
Figure 22. Debit Resettle Bets
9.7. RICH_CONTENT::Betslip
OpenAPI spec available HERE
Table 17. content node (Betslip)
activityType
BsActivityTyp eEnum
Type of activity that occurred. See BsActivityTypeEnum (see Table 18 below)
activityId
ULID
Id of activity from betslip activities node
betslipId
ULID
Betslip identifier
betslip
Betslip
See Betslip (see Table 19 below)
OneOf:
Table 18. BsActivityTypeEnum
PREPARE_PLACE_BETSLIP
All bets, part of the betslip, are placed (initial bet placement) or rolled back. (DEBIT,ROLLBACK)
CONFIRM_PLACE_BETSLIP
Confirms placement of part of the bets and part of the bets are rejected. (CREDIT / return funds of rejected bets). Invoked only in case there are rejected bets.
SETTLE_BETS*
Selected bets are settled. *Part of the Auxiliary API
CASHOUT_BETS
Selected bets are cashed-out (CREDIT)
PAYOUT_BETS
Selected bets are paid out (CREDIT)
CANCEL_BETS
Selected bets are canceled (CREDIT)
RESETTLE_BETS
Bet altered after settlement (DEBIT,CREDIT)
Table 19. Betslip
id
ULID
Betslip identifier. (Same value as in content node (Betslip), see Table 17 above)
context
BsContext
Adds fixed metadata for the whole betslip. See BsContext, see Table 20 above
activities
[ BsActivity ]
Collection of all historical activities that occurred on betslip.
See BsActivity (Table 21 below)
origins
object
Used for omnichannel integration scenarios.
punterIdentities
object
Used for omnichannel integration scenarios.
status
object
Debugging value
Table 20. BsContext
providerBetslipId
ULID
Betslip identifier in provider system.
providerId
Integer
Game provider identifier.
tenantId
UUID
Unique tenant identifier
gameId
Integer
Unique game identifier.
Table 21. BsActivity
type
BsActivityTyp eEnum
See BsActivityTypeEnum (see Table 18 above)
id
ULID
Unique activity identifier
acceptedBet- Ids
[ ULID ]
Present if type = CONFIRM_PLACE_BETSLIP Ids of bets that have been accepted.
rejectedBet- Ids
[ ULID ]
Present if type = CONFIRM_PLACE_BETSLIP Ids of bets that have been rejected.
payoutBetIds
[ ULID ]
Present if type = PAYOUT_BETS__Ids of bets that have been paid out.
cashoutBet- Ids
[ ULID ]
Present if type = CASHOUT_BETS__Ids of bets that have been cashed-out.
betIds
[ ULID ]
Present if type = RESETTLE_BETS__Ids of bets that have been resettled.
originId
integer
Debugging value
currentState
string
Debugging value
state
object
Debugging value
Table 22. Bet
id
string
Bet identifier
selections
[ Selection ]
List of selections. See Table 23 below
bonusWal- lets
[ BonusWallet]
List of possible bonus wallets that can be applied for the bet. See Table 26 below
payin
[ Payin ]
Bet payin. See Table 27 below
pWinnings
PWinnings
Possible winnings after placement.
transactions
object
Wallet transactions that occurred during the bet. Used for debugging.
winnings
Winnings
Bet winnings. See Table 31 below
status
BetStatus
Bet status. See Table 32 below
Table 23. Selection
id
string
Selection identifier
phase
enum
Defines one of the 3 phases of each selection,
oneOf:
OPEN: Selection is open, outcome is not determined
SETTLED: Outcome is determined
LIVE: Selection during cashout
event
object
Unique Event identifier
markets
[ Market ]
Selected markets. Most bets have a single market; multiple markets are reserved for Betbuilder/Custom bet functionalities. See Table 24 below
isBanker
boolean
Is selection a banker?
odds
integer
Odds at bet placement
oddsResolve*
integer
Odds at bet resolve
status*
enum
oneOf:
WON
LOST
VOID
HALF_WON
HALF_LOST
Table 24. Market
id
string
Market identifier.
NOTE: Each game/product has its own market IDs.
baseName
string
Market name in English.
derivedName
string
Market name in the language in which the bet was placed.
tenantName
string
Market name in the main language configured for the tenant.
outcome
Outcome
Market outcome.
Table 25. Outcome
id
string
Outcome identifier.
NOTE: Each game/product has its own market IDs.
baseName
string
Outcome name in English.
derivedName
string
Outcome name in the language in which the bet was placed.
tenantName
string
Outcome name in the main language configured for the tenant.
Table 26. BonusWallet
id
ULID
Bonus wallet identifier
bonusId
ULID
Bonus promotion identifier
Table 27. Payin
bonuses
[ BonusBoost]
See Table 28 below
taxes
[ Tax]
See Table 29 below
payment
object
Based on the type property.
RealMoneyBetPayment (Table 33 below)
GameFreebetBetPayment (Table 34 below)
BonusBetPayment (Table 35 below)
BonusBetCreditsBetPayment (Table 36 below)
Table 28. BonusBoost
id
ULID
Bonus wallet identifier
Table 29. Tax
id
string
Tax identifier
consignee
enum
oneOf:
PLAYER: Tax charged to the player.
COMPANY: Tax to be paid by the operator.
Table 30. PWinnings
min
Winnings
Min possible winnings. See Table 31 below
max
Winnings
Max possible winnings. See Table 31 below
Table 31. Winnings
Table 32. BetStatus
phase
enum
oneOf:
STARTED
PLACED
REJECTED
CANCELLED
SETTLED
PAID_OUT
CASHED_OUT
resolution- Status
enum
oneOf:
OPEN
WON
LOST
Table 33. RealMoneyBetPayment
Table 34. GameFreebetBetPayment
Table 35. BonusBetPayment
Table 36. BonusBetCreditsPayment
type
enum
oneOf:
BONUS_BET_CREDITS
wallet
[BonusBet-Wallet]
Collection of bonus bbet credits wallets
Table 37. BonusBetWallet
id
string
Bonus bet wallet identifier. Ulid type.
bonusid
string
Bonus bet bonus identifier. Ulid type.
10. Casino RICH_CONTENT integration
Rich content integration is designed for operators that require more than basic betting details. If this is not the case, BASIC integration should suffice.
Casino content consists of “transactions” that represent users “spins” or any other mechanic of various casino games.
Casino transactions are separated into "In Session" transactions that occur during gameplay, and "Out of Session" transactions that happen after the playing session (round) has been completed. For “In Session” transactions, punter tokens and round data will be available, whereas for "Out of Session" transactions, there is no such information.
10.1. RICH_CONTENT::Casino
Table 38. content node (Casino)
type
CsnTransacti onTypeEnum
Type of activity that occurred. See CsnTransactionTypeEnum (Table 39 below)
transaction
object
Based on the type property.
BET -> CasinoBetTransaction (Table 40 below)
WIN -> CasinoWinTransaction (Table 41 below)
BATCH -> CasinoBatchTransaction (Table 43 below)
JACKPOT_WIN -> CasinoJackpotWinTransaction (Table 44 below)
BET_ROLLBACK -> CasinoBetTransaction (Table 40 below)
WIN_ROLLBACK -> CasinoWinTransaction (Table 41 below)
PROMO_WIN -> CasinoPromoWinTransaction (Table 42 below)
ADJUST -> CasinoAdjustTransaction (Table 45 below)
OneOf:
Table 39. CsnTransactionTypeEnum
BET
Bet transaction (DEBIT)
WIN
Win transaction (CREDIT)
BATCH
Batch of multiple BET and/or WIN transactions (DEBIT,CREDIT)
JACKPOT_WIN
Jackpot Win transaction (CREDIT)
BET_ROLLBACK
Rollback of Bet transaction (CREDIT)
WIN_ROLLBACK
Rollback of Win transaction (DEBIT)
PROMO_WIN
Promo Win transaction (CREDIT)
ADJUST
Adjustment transaction (DEBIT,CREDIT)
Table 40. CasinoBetTransaction
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform transaction identifier (across all content)
round
CasinoTxRound
Round details. See CasinoTxRound (Table 46 below)
tenantId
UUID
Tenant identifier agreed on integration start
punterId
ULID
Punter’s unique identifier in the operator’s system
game
CasinoTxRound
Game details. See CasinoTxRound (Table 46 below)
type
oneOf:
REGULAR_BET: Bet placed using wallet funds during regular gameplay.
FREE_ROUND_BET: Bet placed as a free spin/free bet. Will not deduct any real money funds.
BONUS_ROUND_BET: Bet placed using wallet funds during bonus round gameplay.
BONUS_BUY: Wallet funds used to buy bonus round bets
jackpotContributions
[ CasinoTxJpc ]
Collection of Jackpot contributions.
See CasinoTxJpc (Table 48 below)
bonus
CasinoTxBonus
Bonus info.
See CasinoTxBonus (Table 49 below)
absolute- Amount
Amount
In cases of free bets, absoluteAmount can contain the value of the free bet, while amount value stays zero (0). See Amount
promo*
CasinoTxPromo
Promo information
vendorData*
string
Raw transaction data for casino vendor.
creationActivity
object
Debugging value
Table 41. CasinoWinTransaction
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform transaction identifier (across all content)
round
CasinoTxRound
Round details. See CasinoTxRound (Table 46 below)
tenantId
UUID
Tenant identifier agreed on integration start
punterId
ULID
Punter’s unique identifier in the operator’s system
game
CasinoTxRound
Game details. See CasinoTxRound (Table 46 below)
type
oneOf:
REGULAR_WIN: Win as a result of a regular bet. FREE_ROUND_WIN: Win as a result of a free round, free spin. BONUS_ROUND_WIN: Win as a result of a bonus round.
bonus
CasinoTxBon us
Bonus info. See CasinoTxBonus (Table 49 below)
promo*
CasinoTxPromo
Promo information
vendorData*
string
Raw transaction data for casino vendor.
creationActivity
object
Debugging value
Table 42. CasinoPromoWinTransaction
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform transaction identifier (across all content)
tenantId
UUID
Tenant identifier agreed on integration start
punterId
ULID
Punter’s unique identifier in the operator’s system
game
CasinoTxRound
Game details.
See CasinoTxRound (Table 46 below)
promo
CasinoTxPromo
Promo information
creationActivity
object
Debugging value
vendorData*
string
Raw transaction data for casino vendor.
Table 43. CasinoBatchTransaction
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform transaction identifier (across all content)
tenantId
UUID
Tenant identifier agreed on integration start
punterId
ULID
Punter’s unique identifier in the operator’s system
bets
[ CasinoBetInBatch ]
Collection of bet transactions
wins
[ CasinoWinInBatch ]
Collection of win transactions
vendorData*
string
Raw transaction data for casino vendor.
creationActivity
object
Debugging value
Table 44. CasinoJackpotWinTransaction
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform transaction identifier (across all content)
round
CasinoTxRound
Round details. See CasinoTxRound (Table 46 below)
tenantId
UUID
Tenant identifier agreed on integration start
punterId
ULID
Punter’s unique identifier in the operator’s system
game
CasinoTxRound
Game details. See CasinoTxRound (Table 46 below)
jackpotId
string
Unique jackpot identifier in the game provider system.
vendorData*
object
Raw transaction data for casino vendor.
creationActivity
object
Debugging value
Table 45. CasinoAdjustTransaction
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform transaction identifier (across all content)
round
CasinoTxRound
Round details. See CasinoTxRound (Table 46 below)
tenantId
UUID
Tenant identifier agreed on integration start
punterId
ULID
Punter’s unique identifier in the operator’s system
game
CasinoTxGame
Game details. See CasinoTxGame (Table 47 below)
reason
TIP_THE_DEALER
GAME_LOGIC_ERROR
vendorData*
object
Raw transaction data for casino vendor.
creationActivity
object
Debugging value
Table 46. CasinoTxRound
id
string
Provider’s transaction identifier
platformId
ULID
Unique platform round identifier (across all content)
status
enum
oneOf:
OPEN: Round is open and subsequent transactions can be expected
CLOSED: Round is closed
Table 47. CasinoTxGame
id
string
Provider’s transaction identifier
platformId
integer
Unique platform game identifier (across all content)
code
string
Provider’s game code
platformCode
string
Provider’s code
Table 48. CasinoTxJpc
id
string
Unique jackpot identifier in game provider system.
name
string
Unique jackpot name in game provider system.
amount
string
Jackpot contribution amount. 10 decimals, in “cents”.
Table 49. CasinoTxBonus
id
string
Provider’s bonus identifier
platformId*
integer
Unique platform bonus identifier (across all content)
Table 50. CasinoTxPromoWin
type
enum
Type of promotional campaign. One of:
TOURNAMENT
BONUS_AWARD
campaignId
string
The unique promo campaign identifier.
reference
string
Unique promo win reference in game provider system.
Table 51. CasinoTxPromoBet
type
enum
Type of promotional campaign. One of:
FREE_ROUND
campaignId
string
The unique promo campaign identifier.
reference
string
Unique promo win reference in game provider system.
freeRounds-Left*
integer
Number of free rounds left in promotion.
freeRounds-Assigned*
integer
Number of free rounds assigned in promotion.
Optional
Table 52. CasinoBetInBatch
id
string
Provider’s transaction identifier.
platformId
ULID
Unique platform transaction identifier (across all content).
round
CasinoTxRound
Round details. See CasinoTxRound (Table 46 above)
game
CasinoTxGame
Game details. See CasinoTxGame (Table 47 above)
type
oneOf:
REGULAR_BET: Bet placed using wallet funds during regular gameplay.
FREE_ROUND_BET: Bet placed as free spin/free bet. Will not deduct any real money funds.
BONUS_ROUND_BET: Bet placed using wallet funds during bonus round gameplay.
BONUS_BUY: Wallet funds used to buy bonus round bets_
jackpotContributions
CasinoTxJpc
Collection of Jackpot contributions. See CasinoTxJpc (Table 48 above)
bonus
CasinoTxBonus
Bonus info. See CasinoTxBonus (Table 49 above)
absolute- Amount
Amount
In cases of free bets, absoluteAmount can contain the value of the free bet, while amount value stays zero (0) See Amount
vendorData*
string
Raw transaction data for casino vendor.
Table 53. CasinoWinInBatch
id
string
Provider’s transaction identifier.
platformId
ULID
Unique platform transaction identifier (across all content).
round
CasinoTxRound
Round details. See CasinoTxRound (Table 46 above)
game
CasinoTxGame
Game details. See CasinoTxGame (Table 47 above)
type
oneOf:
REGULAR_WIN: Win as a result of a regular bet.
FREE_ROUND_WIN: Win as a result of a free round, free spin.
BONUS_ROUND_WIN: Win as a result of a bonus round.
bonus
CasinoTxBonus
Bonus info. See CasinoTxBonus (Table 49 above)
promo*
CasinoTxPromo
Promo information.
vendorData*
string
Raw transaction data for casino vendor.
11. Transfer Wallet Integration
Designed for operators not using Bet Acceptance integration and relying on transfer wallet integration.
For player registration between two systems, refer to the Punter Session Integration (backend) chapter.
11.1. Fetch Wallets (GET)
Used to check the status of the wallet transfer. Initiated by the Operators system.
Table 54. Path Parameters
tenantId
UUID
Tenant identifier agreed on integration start
punterExternalId
string(100)
Punter identifier in operator’s system
Table 55. FetchWalletsResponse
11.2. Wallet Transfer (POST)
Used to transfer funds between systems. Initiated by the Operators system.
Table 56. Path Parameters
tenantId
UUID
Tenant identifier agreed on integration start
Table 57. WalletTransferRequest
Table 58. WalletTransferResponse
11.3. Check Wallet Transfer (GET)
Used to check the status of the wallet transfer. Initiated by the Operators system.
Table 59. Path Parameters
tenantId
UUID
Tenant identifier agreed on integration start
transferId
UUID
Transfer identifier generated by integrator
Table 60. CheckWalletTransferResponse
12. Common Data Types
IP
String in the form of IPv4 or IPv6.
Amount
Monetary amounts are sent as strings and rounded based on the rules defined by each currency.
E.g., EUR 3.3311 will be sent as “3.33”.
Currency
Fiat: ISO 4217 Alpha-3 currency code.
Table 61. Cryptocurrencies
miliBitcoin
xmBTC
6
Tether
xUSDT
6
Bitcoin
xBTC
8
Ethereum
xETH
8
XRP
xXRP
6
Tron
xTRX
6
Litecoin
xLTC
8
Solana
xSOL
6
USD Coin
xUSDC
6
Binance Coin
xBNC
8
TON
xTON
6
DOGE
xDOGE
6
BNB
xBNB
8
DAI
xDAI
6
SHIB
xSHIB
6
PEPE
xPEPE
6
BONK
xBONK
6
MOG
xMOG
6
FARTCOIN
xFARTCOIN
6
TRUMP
xTRUMP
6
AVAX
xAVAX
6
HYPE
xHYPE
6
DateTime
ISO 8601 date and time in UTC, e.g., 2024-03-11T11:39:20.596Z
OneOf:
Table 62. RsStatus
OK
Request is successful
INSUFFICIENT_FUNDS*
Action failed due to insufficient funds.
RISK_VALIDATION
Action failed due to operator risk validation.
INVALID_SESSION
Invalid punter session.
PUNTER_SUSPENDED
Punter suspended from bet placement.
ACCOUNT_RESTRICTION_LIMIT_REACHED
Punter reached daily wagering limits.
INTERNAL_ERROR
Reserved for errors that cannot be matched with statuses above.
DEBIT_REJECTED
Debit rejected for reason cannot be matched with statuses above.
Table 63. Punter
id
ULID
Unique punter identifier in iGNITE system
externalId
string(100)
Punter identifier in operator’s system
sessionToken*
string(1000)
Session identifier in operator’s system (if applicable)
Table 64. Wallet
id
string(100)
Wallet identifier. If not available in the Operator system any random string value should be set
type
enum
oneOf:
REAL: Holds real money funds
BONUS: Holds bonus money or other bonus funds
version
Integer
Balance version. If not available, set a UNIX timestamp of when the request is generated. Value is used to handle race conditions between frontend and backend passed balances
options*
string(1000)
Node reserved for special bonus scenarios
Table 65. GameInfo
gameId
Integer
Unique Game identifier defined at integration start.
13. Examples (Betslip)
Examples of requests to be received by the operator platform in case of betslip contentType
14. Examples (Casino)
Examples of requests to be received by the operator platform in case of casino contentType
Last updated
Was this helpful?