What you are building
Game Alligators (GA) puts game studios’ games into your casino. Traffic runs in two directions, each with its own key pair. Don’t mix them.
| Direction | Who calls whom | What it’s for | Key you use | Chapter |
|---|---|---|---|---|
| You → GA | You call https://api.rexplay.site/v2/… | Launch a game, read the catalog, issue free rounds, read reports | Operator API key + hash-based message authentication code (HMAC) secret, from your onboarding profile | 4 |
| GA → you | GA calls your wallet at https://<your-host>/v2/wallet/* | Balance, bets, wins, rollbacks | Wallet signing key, from the Operator Portal. GA signs, you verify | 5 |
Transports: HTTP/JSON, which this guide covers, or native gRPC with the same messages. On gRPC there is no HMAC signature in either direction: the credential travels as metadata (x-api-key plus ga-brand-id on calls to your wallet, x-api-key plus x-brand-id on your calls to GA). If you already run a Softgaming-compatible wallet API, ask GA about the compatibility adapter. A separate document covers it.
One session, end to end
Player Your site GA Your wallet
| click game | | |
|------------------>| launch_game | |
| |---------------->| (token, player, currency) |
| |<----------------| launch_url, session 24h |
|<------------------| open launch_url | |
| | | get_balance / authenticate |
| | |--------------------------->|
| | |<---------------------------| balance
| spin | | debit (op_id A) |
| | |--------------------------->|
| | |<---------------------------| ok, balance_after
| | | credit (op_id B, win) |
| | |--------------------------->|
| | |<---------------------------| ok
| spin, no answer | | debit (op_id C) ... 5 s per attempt, 8 s per bet
| | |--------------------------->| (timeout)
| | | rollback (original C) |
| | |--------------------------->|
| | |<---------------------------| ok, original_found: false
| | | (late debit C arrives -> you refuse ALREADY_ROLLED_BACK)