Integration model
Every external service reaches the platform through an adapter that implements the contract of its category. The platform talks to the contract, never to the provider directly.
01Adapter categories
A category defines what an adapter must be able to do. The provider behind it can change without the rest of the platform noticing.
games.*
Studios and content aggregators that supply casino games.
The contract covers
sportsbook.*
External sportsbook services that supply fixtures, markets, prices and results.
The contract covers
payments.*
Providers that move money between players and the operator's accounts.
The contract covers
kyc.*
Identity verification, screening and monitoring services chosen by the operator.
The contract covers
messaging.*
Channels and tools that communicate with players on the operator's behalf.
The contract covers
export.*
Destinations for operational data: warehouses, BI tools and regulatory reporting.
The contract covers
02Integration model
The categories differ in what they do. They share how they behave when something goes wrong.
Every adapter in a category implements the same operations with the same semantics.
Timeouts, retries with backoff and circuit breaking are applied per adapter. One failing provider does not take the others with it.
Any operation that touches the wallet is idempotent and can be reconciled against the provider's own records.
Latency, error rate and circuit state per adapter are shown in the console and available through the API.
Each category has a sandbox adapter with generated data, so your developers can test without a provider account.
// Illustrative shape of a game source adapter. Not a published SDK.
export interface GameSourceAdapter {
listGames(market: string): Promise<CatalogEntry[]>;
createLaunch(request: LaunchRequest): Promise<LaunchSession>;
// Wallet operations are idempotent: same key, same result.
onDebit(event: RoundDebit): Promise<WalletResult>;
onCredit(event: RoundCredit): Promise<WalletResult>;
onRollback(event: RoundRollback): Promise<WalletResult>;
health(): Promise<AdapterHealth>;
}Illustrative shape, not a published SDK. Contracts are documented per category during onboarding.
03Onboarding an adapter
The same six steps whether the adapter already exists or has to be built. The difference is how long the middle takes.
01
Agree which provider, which markets and which operations the adapter must support.
OutputIntegration brief
02
Map the provider's protocol to the category contract and document every difference.
OutputMapping document
03
Implement or enable the adapter against the provider's test environment or a simulator.
OutputSandbox adapter
04
Run the category test suite: idempotency, retries, rollbacks, timeouts and reconciliation.
OutputTest evidence
05
Enable the adapter for one brand or market first and watch its health before widening.
OutputGo-live checklist
06
Monitoring, alerts and reconciliation run continuously. Provider changes are handled as adapter updates.
OutputRunbook
04Statuses
You will see these three words next to adapters in our documentation and in the console. They describe the state of the software, not a commercial relationship.
The adapter is built and has passed its conformance tests. It can be enabled on a production tenant once your own agreement with the provider is in place.
What it means for you
The adapter runs in the sandbox, against a simulator or the provider's own test environment. It is for building and testing, not for real traffic.
What it means for you
The category contract supports the connection, but the adapter has not been built. It is scoped and scheduled with the operator that needs it.
What it means for you
We do not publish a partner list. Which providers are connected depends on each operator's licences and agreements, and is confirmed during discovery.
Next step
Share your provider list and markets. We will map them to adapter categories and show you the work involved.