Casino API Integration: How Game and Wallet APIs Actually Work
For an operator, a casino API integration is a wallet problem before it is a catalogue problem. This iGaming API guide follows the two directions of traffic: the launch call the platform sends, and the wallet callbacks a game provider sends back for every bet and win.
A casino game API is the interface a game provider exposes so an operator platform can open a game session and settle every bet and win against the player wallet. It covers three contracts: a launch call that returns a session URL, wallet callbacks the platform must answer, and a reporting feed used for daily reconciliation.
Every casino build reaches the same point: the games arrive through somebody else's application programming interface (API).
What is a casino game API, and what does it actually connect?
A casino game API is the connection between a game provider remote gaming server (RGS) and an operator platform. The provider hosts the game logic and the random number generator (RNG). The operator holds the player account management (PAM) system, the wallet and the money.
The API does four jobs: launch a session, authenticate it, settle every transaction against the wallet, and report the rounds afterwards.
Launch, authenticate, transact, report: the four jobs
- Launch
- The platform asks the provider to open a session for one player in one currency, and receives a single use launch uniform resource locator (URL).
- Authenticate
- Every call in both directions is signed, so each side can prove who sent it.
- Transact
- The provider calls your wallet for every bet and win, and the answer carries the resulting balance.
- Report
- A rounds feed lets finance reconcile the wallet ledger against the provider's record of play.
The iGaming glossary defines those acronyms and the rest of the vocabulary used here.
Where the game server ends and the platform begins
The boundary is custody: the game holds no money. The remote gaming server runs the game logic, the RNG and the return to player (RTP) model, then asks the platform for every movement of value.
The platform holds the player record, the know your customer (KYC) status, the balance and the audit trail. That is why choosing a casino platform caps what the wallet can do.
Which APIs make up a casino integration?
A casino integration is made of four call families rather than a single interface. The game launch call runs from the platform to the provider and returns a single use session URL.
The wallet callbacks run the other way, from the provider to the platform, for balance, bet, win and rollback. Catalogue and reporting calls run from the platform. Back office calls cover campaigns, jackpots and health.
| Call family | Direction | Typical parameters | Idempotent? | What breaks without it |
|---|---|---|---|---|
| Game launch | Platform calls provider | player reference, game identifier, currency, language, mode (real or demo), return URL, jurisdiction | Not required | The player cannot open a game |
| Balance | Provider calls platform | player reference, currency, session token | Read only, safe to repeat | The game cannot show a balance or validate a stake |
| Bet (debit) | Provider calls platform | player reference, round identifier, transaction reference, amount, currency, game identifier | Required | Retried debits take the stake twice |
| Win (credit) | Provider calls platform | player reference, round identifier, transaction reference, amount, currency | Required | Retried credits pay the win twice |
| Rollback | Provider calls platform | transaction reference of the call being reversed, round identifier | Required, including for a transaction you never received | The provider retries forever and the round never closes |
| Catalogue | Platform calls provider | provider filter, currency, jurisdiction, pagination cursor | Read only | New titles never appear in the lobby |
| Rounds and reporting | Platform calls provider | date range, currency, pagination cursor | Read only | Nothing to reconcile the wallet ledger against |
| Live lobby | Platform calls provider | game identifier, currency | Read only | Live tables render without limits, seats or dealer data |
Method names vary by supplier. The call families do not. Three independent supplier documentation sets, read on 26 August 2026, expose six, four and five methods respectively for the same work.
The game launch API
The platform sends a player reference, a game identifier, currency, language, mode (real money or demo) and jurisdiction, and gets back a short lived launch URL the client opens. Demo mode is the same call with no real player attached. Live tables add a lobby lookup in front of it, and the vertical specifics belong to live dealer casino software.
The wallet API: the callbacks the platform must expose
Here the direction reverses. Once the session is open, the provider calls the platform for balance, bet, win, refund and rollback, and expects the resulting balance in the response. Most of these interfaces are representational state transfer (REST) over HTTPS carrying JSON, but the shape of the contract decides whether the integration survives a bad network day.
Back office, catalogue and reporting APIs
Catalogue calls sync the title list and its metadata, including RTP figures and jurisdiction restrictions. A back office API covers free spin campaigns, jackpot feeds and a health endpoint. The rounds report matters most at month end: it is the provider's record of play, and what a daily reconciliation joins the wallet ledger against.
Seamless wallet or transfer wallet, and why seamless won
A seamless wallet keeps one live balance on the operator platform and settles every bet and win through a callback in real time. A transfer wallet moves money into a provider held sub balance at the start of a session and back out at the end.
Seamless is now the default because deposit limits, self exclusion and cross provider bonuses only work when there is one balance to check.
What a seamless wallet actually demands of you
It asks the platform to behave like a payment system. The bet path has to answer in well under a second, because a player is waiting on a spin, and the endpoint has to stay available whenever a game is open.
The payoff is one balance across every provider and vertical, owned by the PAM system. The cashier is a different contract, and how the cashier works is covered separately.
Idempotency, rollback and the double credit race
Idempotency means a repeated call produces the result of the first call, not a second effect. Game providers retry on timeout with the same transaction reference, so a bet callback that is processed twice debits the stake twice.
Store the transaction reference with a unique database constraint at the money mutating layer, not in an application cache, and return the stored response for any retry.
The race is narrower than it looks: two copies of the same callback can arrive milliseconds apart and both read an empty ledger before either writes, so only a constraint the database itself enforces settles it.
A reversal is the second landmine. A provider may ask you to reverse a bet you never applied, because its own request timed out on the way in. That call must return success and record a tombstone, so a late arrival of the original bet is refused instead of applied.
Disconnects follow the same logic. A player who drops mid round leaves the round open, and it closes later through a win, a settlement replay or a reversal. Treat the callback as the only source of truth for money.
Webhook retry and replay are normal operation, not an incident. Providers replay hours of events after an outage, so persist the payload, verify the signature, answer fast and process asynchronously.
One decision here is close to irreversible: at least one supplier states that a brand's wallet mode is chosen once per integration and cannot be changed afterwards.
How does a casino API integration work, step by step?
A casino API integration runs in six stages: commercial scope and contract, sandbox credentials, the game launch flow, the wallet callbacks, a conformance run against the provider test suite, then production keys and a monitored soft launch.
The wallet callbacks are the long pole. They are the only part where the provider calls you, and the only part where a bug moves real money.
The six stage sequence
- Agree scope, markets and commercial terms. The markets named here decide the certification work later.
- Take sandbox credentials and signing secrets, and confirm which addresses each side calls from.
- Implement the game launch call and prove a session opens in demo mode.
- Expose and harden the wallet callbacks, including duplicates, reversals and disconnects.
- Run the conformance scenarios against the provider test suite and fix what they find.
- Promote to production and soft launch on one provider with capped stakes.
The order of a casino API integration is not cosmetic: no sandbox key, no launch call, and nothing to call your wallet. Wiring a provider into a platform that already runs is custom iGaming development.
Authentication: signing, allowlisting and single use tokens
Casino game APIs authenticate with a keyed hash message authentication code (HMAC) signature over the raw request body, carried in a header alongside a timestamp and a nonce. The timestamp window and the nonce store give replay protection.
Mutual internet protocol (IP) allowlisting restricts who can call the endpoint at all. Launch tokens are single use and short lived. Never a static key in a query string.
Two entries in the OWASP API Security Top 10, 2023 edition, name this surface: API2:2023 Broken Authentication and API10:2023 Unsafe Consumption of APIs. The second is the operator blind spot, because a wallet endpoint consumes third party calls by design.
Why published timelines disagree
Published casino API integration timelines disagree by two orders of magnitude, and the reason is structural. One vendor advertises a three to seven day setup. One consultancy budgets six to ten weeks of engineering per direct provider, plus quality assurance, legal review and certification.
Both are real: switching on a catalogue behind an existing wallet is not the job of building a callback contract for one more studio.
What has to pass before a casino API goes live?
Two things have to pass before a casino API goes live: the provider conformance suite and, in regulated markets, an accredited laboratory. The conformance suite exercises bet, win, rollback, disconnect mid round, duplicate transaction reference, insufficient funds, currency mismatch and a full day reconciliation.
Laboratory work is separate. eCOGRA states that integration testing is increasingly mandated by iGaming jurisdictions.
The conformance scenarios
- Bet and win on a normal round, then the same round replayed.
- Reversal of an applied bet, and of one you never received.
- A duplicate transaction reference arriving after a timeout.
- Disconnect mid round, then settlement when the player returns.
- Insufficient funds, and a stake larger than the balance.
- Currency mismatch between the session and the wallet.
- Session expiry while a round is still open.
- A full day reconciliation against the rounds report.
The duplicate case and the disconnect case are the two that fail in production, and the two most often skipped in testing. eCOGRA, an accredited testing agency, publishes an integration testing service and lists twenty jurisdictions where it performs it, including Ontario, the Netherlands and Sweden (retrieved 26 August 2026).
Certification: which standard applies, and who owns it
Gaming Laboratories International (GLI) publishes GLI-19 Interactive Gaming Systems v3.0 as its interactive gaming systems standard, and lists GLI-33 Event Wagering Systems v1.1 separately. Certification of the games themselves, including the number generator, belongs to the supplier, and RNG certification is a different exercise from testing an integration.
Certificates are market specific, so a title cleared for one jurisdiction does not travel to the next. The UK Gambling Commission's remote gambling and software technical standards page names licence condition 2.3.1 and requirements for the timing and procedures of testing (last updated 29 January 2026), which is why your gaming licence sets the testing calendar.
Promoting from sandbox to production
A casino API integration is not finished when the code passes. Sandbox and production get separate credentials, separate signing secrets and separate allowlists, and production keys follow a passing test run.
Then a monitored soft launch: one provider, capped stakes, and the wider catalogue switched on only once the daily reconciliation has matched for several days. Reconcile from day one, not from the first discrepancy.
Aggregator API or direct provider API?
An aggregator gives a single integration and one wallet build covering many studios. A direct provider API gives one integration per studio, repeated every time a studio is added, and every studio has its own callback contract.
The aggregator charges a margin on top of the studio revenue share. Direct wins only on an exclusive, a bespoke commercial term, or volume large enough to outrun that margin.
| Dimension | Aggregator API | Direct provider API |
|---|---|---|
| Integrations to build | One, covering many studios | One per studio, repeated for every provider added |
| Wallet work | Written once | Repeated, and every provider's callback contract differs |
| Cost shape | Studio revenue share plus an intermediary margin on the traffic it routes | Studio revenue share only, plus your own engineering and certification cost |
| Time to a live catalogue | Fast. One test cycle | Slow. Published estimates run to several weeks of engineering per provider |
| Where it wins | Almost always at launch, and for any operator running a broad catalogue | A headline exclusive, a bespoke commercial term, or volume high enough that the intermediary margin exceeds the engineering cost |
Revenue share and engineering estimates as published by gambling-soft.com, retrieved 26 August 2026, and casinowebscripts.com, retrieved 26 August 2026. Commercial terms are negotiated per operator and vary by market, volume and licence.
One consultancy publishes studio revenue share at 8 to 15 percent of gross gaming revenue (GGR) for small to mid operators, sliding to 5 to 8 percent at serious volume, with an intermediary margin of 1 to 4 percent on the traffic it routes (2026 market rates). A second source puts that cut at 1 to 5 percent, and neither published an average.
Its worked example reads the table for you: 12 percent to the studio plus 2 percent on top is 14 percent of gross revenue on those games. The same source reports that an average casino earns its turnover on 150 to 300 games, which makes catalogue size a poor tiebreaker.
For most operators the answer is one integration layer. A casino game aggregator gives one contract, one wallet build and one test cycle across many studios, with integrated game providers behind it. A direct casino game provider API earns its cost only when the case is specific, such as an exclusive negotiated with a studio the size of Evolution.
A turnkey online casino platform or a white label iGaming platform is the third route: the game layer arrives already wired, which moves the work rather than removing it.
Frequently Asked Questions
Scope your casino API integration with OHS Gaming
Wallet contract design, test scenarios, certification scope and a dated integration plan.
Talk to an Integration Specialist
