Introduction & concepts

This site is for providers — the game studios that build the games running inside a moose-platform operator's page. It does not cover the operator side (launching sessions, embedding the iframe, the shell-side bridge) beyond what you need to know as context.

Three message directions

Your integration touches three independent channels. 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:

Direction	Transport	Who signs	Examples
Provider → platform	Signed HTTP, you call	You	verifySession, submitTransaction, getBalance
Platform → provider	Signed HTTP, platform calls	You (verify)	Session revoke, free spins grant/status/cancel
Game → shell	Browser postMessage, one-way	N/A (same-origin trust via envelope + origin checks)	GameBridge's lifecycle events

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

Two SDKs, two runtimes

• @moose/provider-sdk runs on your backend (the RGS — remote game server). It signs and sends the provider → platform calls, and verifies the platform → provider calls. Your HMAC secret lives here, and only here.
• @moose/game-client-sdk runs in the browser, inside the iframe the operator embeds. It reports your game's lifecycle to the shell and collects a bot-detection digest. It never sees your secret — it has no way to sign anything, by design.

If you take away one rule from this page: the secret never leaves your backend. Every page that follows assumes it.

Core invariants

These hold across every endpoint and every page in this site — worth internalizing before diving into the guides:

• Amounts are always integers in the currency's minor unit (e.g. cents for USD) — never floats. 100 means $1.00. currency is always an uppercase 3-letter ISO-4217 code.
• Identity is never trusted from a request body. Your provider identity comes from your signature; a player's identity comes from their session token. There's no providerId or playerRef field you set that the platform simply believes.
• Idempotency is always keyed by an ID you generate: transactionId for wallet calls, requestRef/externalRef for free spins. Reuse the same ID across retries of the same logical attempt — the SDK does this automatically for its own retries.
• 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.
• Wiring your backend? Server-side integration.
• Wondering where the session token comes from? Getting the session token.
• Getting a 401 you can't explain? Debugging.
• About to ship? Go-live checklist.