How to integrate a casino API, step by step

Step 1 — Get sandbox keys and understand the auth model

Before a single game loads you need an API key pair and a signing secret. Every request you send is signed, and every callback you receive is signed back to you, so the secret never travels over the wire. AS Tech API issues separate sandbox and production credentials, and the sandbox carries the full catalogue so you are not testing against a cut-down set of games.

The signature is an HMAC-SHA256 over the exact raw request body. The two mistakes that cost teams a day each: re-serialising the JSON before hashing (whitespace changes break the digest) and hashing a parsed object instead of the raw string. Capture the raw body first, verify, then parse.

• Store the signing secret server-side only — never in the client bundle
• Hash the raw body bytes, not a re-encoded object
• Reject any callback whose signature does not verify, with an explicit fail status
• Keep sandbox and production secrets in separate stores so they cannot be swapped

Step 2 — Pull the catalogue and map it to your lobby

The catalogue endpoint returns every game available to your account: provider code, game code, name, category, thumbnail and the currencies in which the game actually launches. Store it in your own database rather than calling it per page view — refresh it on a schedule, typically daily.

The field that operators underuse is currency support. A provider being 'live' does not mean it opens in every currency. AS Tech API verifies support with real launch probes per currency, so the catalogue tells you which studios genuinely open in BRL, INR, PHP, VND or PYG instead of failing in front of a player.

• Cache the catalogue locally; refresh daily, not per request
• Filter your lobby by the player's wallet currency at query time
• Keep your own category mapping — provider categories are inconsistent across studios
• Handle new games appearing automatically; do not hardcode game lists

Step 3 — Launch a game session

The launch endpoint takes a player identifier, a currency, a game code, a language and an exit URL, and returns a URL you load in an iframe or redirect to. That is the whole flow. The session is bound to the player and currency you sent, so there is nothing to keep in sync afterwards.

Use a stable internal player ID, not an email or username that can change. Every round, transaction and report downstream keys off that identifier, and changing it later orphans the history.

Step 4 — Implement the seamless wallet callback

This is the only endpoint you have to build, and it is where integrations actually fail. In seamless mode your wallet stays the single source of truth: the aggregator calls you for balance, bet, win and rollback, and your response decides whether the round proceeds.

Three rules make it reliable. Be idempotent per transaction ID — the same bet ID may arrive twice and must debit once. Be fast — answer inside a couple of seconds or you will see timeouts on high-frequency games. And be explicit about failure: when you refuse a bet, return a fail status, not a 200 with an empty body, or the round can settle against a debit you never made.

• Idempotency key: the provider transaction ID, stored with a unique index
• Answer balance, bet, win, rollback and bonus-round operations
• Return the player's post-operation balance in every successful reply
• Return an explicit fail status with the current balance when you decline
• Log the raw request body for every callback — disputes are resolved from it

Step 5 — Test before production

Run the whole loop in sandbox: launch a game, place a real round, force an insufficient-funds refusal, and force a rollback. Then check that your ledger balance and the reported round history agree exactly. AS Tech API stores every round and every callback with its payload, so you can reconcile line by line rather than guessing.

Once sandbox reconciles, production is a credential swap. Most partners go live the same week they start.

• Happy path: bet, win, balance after — all three agree
• Refusal path: declined bet leaves no debit and no settled round
• Rollback path: the original debit is reversed exactly once
• Duplicate path: the same transaction ID twice moves money once