Integration
Authentication and security
API key#
Every server-to-server call carries two body fields:
| Field | Meaning |
|---|---|
partner | Your project id |
api_key | Your project's secret key |
There are no signatures or tokens in headers: the key travels in the JSON body over HTTPS. Keep it only on your server — never in a browser, mobile app or log. A request with an unknown partner or a wrong api_key is answered with HTTP 401 UNAUTHORIZED (the two cases are indistinguishable on purpose).
Public read-only endpoints need no key: GET /games/health, GET /capabilities, GET /health, GET /docs/openapi.json.
IP allowlist#
POST /gameActions.do and POST /playerRtp.do additionally require the caller's IP address to be inside one of the networks allowed for the project; otherwise the answer is HTTP 403 IP_NOT_ALLOWED.
- Networks are written as CIDR, IPv4 or IPv6 (
203.0.113.0/24,203.0.113.7/32,2001:db8::/32). - The allowlist is managed by the platform owner in the admin panel, section IP Whitelist — see Access, staff and history.
- Make every server call from the same fixed addresses and ask for exactly those to be allowed. IPv4-mapped IPv6 addresses are treated as their IPv4 form.
Rotating the API key#
The owner can reveal or regenerate the key in the admin panel (Projects → project → Integration):
- Reveal shows the current key and is recorded in the audit log.
- Regenerate asks you to type the project id as confirmation, creates a new key, and the old key stops working immediately. Install the new key on your server before regenerating if you cannot tolerate failed calls, or be ready to deploy it at once.
- The panel shows a fingerprint of the key so you can check which key a server uses without exposing it.
Projects that are internal to the platform (demo and site wallet) have a read-only key.
Verifying the platform's callbacks#
The platform calls your wallet with the same api_key in the JSON body of every callback. Compare it with your stored key (in constant time) and reject the request on a mismatch. In addition:
- accept callbacks only on an
https://address you control; - the platform does not follow redirects and waits at most 2 seconds for an answer;
- the callback URL must be public:
https://, port 443, no user info, query or fragment, no trailing slash, at most 512 characters, and a host that resolves to public addresses only.
Details and examples: Wallet callbacks.
Idempotency and replays#
Mutating methods accept an Idempotency-Key header, and every wallet operation carries a unique transaction id — both protect against duplicates after a timeout. See Conventions.
Security checklist#
- [ ] The key is stored in a secret manager or environment variable.
- [ ] Calls are made from allowlisted servers only.
- [ ] The wallet endpoint verifies
api_key, uses HTTPS and is idempotent. - [ ] Logs never contain the key or the game
link. - [ ] Staff accounts in the admin panel have the minimum permissions and projects they need (Staff).