Games
GET /games scope: games:read
Returns the game catalog filtered to this casino's allowlist.
{
"games": [
{
"id": "sweet-bonanza",
"game_key": "pragmaticexternal:SweetBonanza",
"display_name": "Sweet Bonanza",
"provider": "pragmaticexternal",
"rtp": 96.6,
"status": "validated"
}
]
}
| Field | Notes |
|---|---|
id | What you pass as game_id when creating a battle |
game_key | Provider-qualified, provider:GameName |
display_name | Falls back to a prettified id when the game has no profile |
provider | Derived from game_key, before the colon |
rtp | Percentage. 0 means the game has no profile, not an RTP of zero |
status | validated or planned |
status
validated has been verified end to end: the recording recipe works, the bonus buy lands,
and the video comes out watchable.
planned means a recipe exists but no profile does. It appears in the catalog rather than
being dropped, so an operator can see it coming. Treat it as not ready to sell.
An empty allowlist returns an empty catalog
{ "games": [] }
A casino with nothing allowed sees zero games, and every POST /battles fails with
403 game_not_allowed. Allowing games is part of onboarding.
Use the console's game screen if you have access to it; otherwise ask your host to allow the games you agreed on.
Allowlist changes can take up to 30 seconds
The catalog this endpoint serves is cached, so an allowlist change is not always visible on the next call.
A change made in the console appears at once. A change your host makes for you can take up to 30 seconds to reach this API: the write succeeded and the change is real, but it has not propagated yet.
Verified live: GET /games kept returning {"games":[]} and POST /battles kept returning
game_not_allowed for about half a minute after the change was confirmed.
If a game you just had allowed is still missing, wait half a minute and call again before debugging anything else. This window is the most commonly misdiagnosed symptom in SlotBattle, because it reads as a broken integration.
The catalog is not per-player
GET /games answers what the casino may run. Which of those a given player may play,
covering jurisdiction, age, self-exclusion and responsible-gaming limits, is your backend's
decision, and SlotBattle knows nothing about it.
Next
- Battles: using a
game_id - Tenancy: how allowlists are scoped
- Games in the console