Introduction & concepts

This site is for operators — the casino sites/apps that have the players and embed games from the Moose Gaming Platform's catalog. It does not cover the provider side beyond what you need to know as context.

One integration, all games

You don't integrate with each game studio individually. You integrate once with the Moose Gaming Platform, and every game any studio publishes to the platform becomes launchable the same way: one signed API call, one wallet callback contract, one shell-side message protocol — regardless of which studio built the game.

Three surfaces you touch

Your integration has three independent parts. They're easy to conflate because they all move data between "your side" and "the platform," but each has a different caller, transport, and trust model:

Surface	Transport	Who signs	Examples
Operator API (you → platform)	Signed HTTP, you call	You	Launch a session, list your catalog, kick a player, mint a replay link
Wallet callback API (platform → you)	Signed HTTP, platform calls	Platform (you verify)	Settle a BET/WIN/ROLLBACK, answer a balance query
Game → shell bridge	Browser postMessage, one-way	N/A (same-browser trust via envelope + origin checks)	Game lifecycle events reported up to your embedding page

The first two share the same HMAC scheme in both directions — see Signing & authentication. The third is unrelated to signing entirely: it's a same-browser message between the game's iframe and your page, validated by origin and an envelope marker instead of a cryptographic signature — see Shell bridge.

The Moose Gaming Platform never holds funds

This is the single most important thing to internalize: the Moose Gaming Platform is a seamless-wallet aggregator. It never custodies player money. Your own wallet is the one and only source of truth for a player's balance — the platform's job is to route every bet and win to it in real time, in order, exactly once. That's what the wallet callback API exists to do, and it's the part of this integration worth the most care.

Core invariants

These hold across every endpoint on both directions — worth internalizing before diving into the guides:

• Amounts are always integers in the currency's minor unit (e.g. cents for USD) — never floats. 500 means $5.00. currency is always an uppercase 3-letter ISO-4217 code.
• Identity is never trusted from a request body. Your operator identity comes from your signature; a player's identity comes from playerRef/sessionToken, resolved server-side against the session your own launchGame call created.
• Idempotency is always keyed by an ID the caller generates: transactionId for wallet calls, requestRef/idempotencyKey for free spins. Whichever side receives a retry must answer it with the same response it gave the first time, not re-apply the effect.
• WIN is a separate transaction from its BET, not a field on the same request. Whichever of the two ends the round carries roundComplete: true.

See Data model & enums for the full field-level reference behind these rules.

Where to go next

• New to this integration? Start with Getting started.
• Ready to launch your first session? Launching games.
• Building your seamless wallet backend — the main piece of work? Implementing the wallet callback.
• About to go live? Go-live checklist.