Game aggregation
Provider games normalized into one catalogue. Withdrawn games are archived, never deleted.
Learn moreB2B casino game aggregation platform
One API. One catalogue. One ledger.
A unified integration layer for operators: aggregate casino content, control who can launch what, and keep every wallet movement in an auditable ledger.
- Versioned REST APIOpenAPI contract
- Idempotent ledgerAppend-only records
- Tenant isolationPer-operator data
- EN · FR · ARFull RTL support
Our solutions
Everything the aggregation layer needs, in one platform
Six areas of the platform, each one implemented and testable in the sandbox today.
Screenshot of the game catalogue
Provider management
Lifecycle, health, credentials and synchronization history for every provider adapter.
Learn more
Operator catalogue
Each operator enables, features and orders exactly the games it may offer.
Learn more
Operator management
Tenants, roles, scoped API keys, country blocks and a full audit history.
Learn more
Analytics and reporting
Per-currency revenue reports, settlements and statement reconciliation.
Learn more
Integration infrastructure
Signed webhooks with retries, a versioned REST API and a sandbox.
Learn moreChoose your integration
Four ways to start, no price list
Commercial terms are agreed per project. Pick the path that matches where you are and we will scope the rest together.
Available today
Sandbox evaluation
- Simulated provider and credits
- Operator portal and API keys
- Full ledger and reports
- No real-money operations
Available today
REST API integration
- Versioned REST API v1
- OpenAPI contract
- Idempotent wallet operations
- Signed webhooks with retries
Available today
Operator-held wallet
- Signed wallet callbacks
- Unknown-outcome recovery
- Balances stay with the operator
- Reconciliation against the ledger
Not integrated yet
Provider onboarding
- Adapter contract and capabilities
- Built from official documentation
- Credentials stored write-only
- Live only after verified tests
Why choose this platform
Built for operators who need control
- Unified APIOne versioned contract
- Tenant isolationEnforced and tested
- Immutable ledgerAppend-only, idempotent
- Audit and webhooksEvery change recorded
- Three languagesEnglish, French, Arabic
Integration standards
Standards-based interfaces, no borrowed logos
What you integrate against today. Provider partnerships are announced only once an integration is verified.
- REST / JSON
- OpenAPI 3
- HMAC-signed webhooks
- Idempotency keys
- CSV export
- Sandbox environment
- Provider adapters · not integrated
See it in action
Explore the live console
Walk through the provider registry, catalogue controls, ledger and reports with a sandbox operator. Everything you see runs on simulated credits.
Platform architecture
From provider to reconciled ledger, one path.
The same six layers exist in the code today. The first layer is represented by a simulated provider until real, authorized integrations are added.
- Authorized providersSandbox provider (simulated) · others not connected
- Adapter layerAuthentication · catalog · launch · callbacks
- Aggregation coreCatalog · sessions · wallet ledger · reporting · audit
- OperatorsREST API v1 · wallet callbacks
Implemented (simulated sandbox provider)Dashed: provider slot, not connected
- Authorized providers
Simulated sandbox provider today; others only after documentation, credentials and verified tests.
- Provider adapter layer
Typed adapters keep provider-specific signing, HTTP and errors out of controllers and wallet logic.
- Unified aggregation core
Normalized catalog, availability rules, tenant isolation, audit trail.
- Game catalog and launch sessions
Expiring sessions whose tokens are stored only as hashes.
- Operator API and wallet callbacks
Operator REST API and signed provider callbacks, both idempotent.
- Reporting and reconciliation
Per-currency reports, settlements and reconciliation against provider statements.
Platform specification
The platform, specified.
What is implemented today, stated plainly. Nothing in this table is a roadmap item.
- Connection model
- Versioned REST API v1 with an OpenAPI contract, signed provider callbacks and signed operator webhooks.
- Game catalogue
- Provider games normalized into one model. Games a provider withdraws are archived, never deleted, so history stays intact.
- Operator control
- Per-operator game availability, featured ordering, country blocks, scoped API keys with rotation and revocation.
- Wallet and ledger
- Idempotent, row-locked, append-only ledger. An internal sandbox wallet, or an operator-held wallet reached through signed callbacks.
- Reporting
- Per-currency revenue reports with CSV export, immutable settlements, and statement reconciliation against the ledger.
- Operations
- Correlation identifiers, an audit log, health checks and webhook delivery with bounded retries.
- Languages
- English, French and Arabic, with correct right-to-left layouts.
- Providers today
- A simulated sandbox provider is available. Real providers connect only after official documentation, credentials and verified integration tests.
What is game aggregation?
Instead of integrating every game provider separately, an operator integrates once with an aggregator. The aggregator connects to providers, normalizes their games into one catalog and routes launches and wallet traffic.
How does the unified API work?
Operators call a versioned REST API under /api/v1 with a bearer key: list and launch games, call the wallet, read transactions and reports. Money is integer minor units and every wallet call carries an idempotency key. The OpenAPI document is the contract.
How are provider integrations configured?
A platform administrator registers a provider, stores its credentials (write-only, encrypted), runs a health check and a catalog sync, and moves it through draft, testing and active. A non-sandbox provider cannot be activated without an authorization reference and verified integration tests.
How does the sandbox work?
A deterministic simulated provider, simulated credits (currency XTS) and a scenario runner for duplicates, out-of-order callbacks and retries. Launch URLs are simulated. Real-money operations are disabled.
How are wallet callbacks processed?
Provider callbacks are verified (signature, timestamp, single-use nonce for the sandbox provider), mapped to a launch session and applied through one wallet engine that is idempotent, row-locked and append-only. In operator-wallet mode the operator remains authoritative and unknown outcomes are rolled back or recovered with the same transaction id.
How is reconciliation performed?
Provider statements are imported and compared with the ledger. Missing, mismatched and duplicate lines become exceptions that people review and annotate; reconciliation never edits ledger history. Today this is verified against synthetic statements only.
What is required to start an integration?
For the sandbox: an operator account and an API key, which we issue after a conversation. For a real provider: that provider’s documentation, credentials, a commercial agreement and verified tests. Licensing and regulatory obligations remain with the operator.
Which integrations are currently available?
The simulated sandbox provider only. No third-party studio is listed as integrated, and none is implied.
Ready to connect?
Scope your integration with us
Tell us about your operation and where your project stands. We will arrange a demo in the sandbox environment.