What you receive
You are integrating against an instance the platform runs. You operate no infrastructure and deploy nothing. This page lists what you should have in hand before writing any code.
The handover list
| Item | Example | Without it |
|---|---|---|
| REST base URL | https://slotbattle.platform.com | Nothing works |
| WebSocket base URL | wss://slotbattle.platform.com | Check whether ws_url in responses is already correct |
| Tenant id | acme | You will see it in events and webhooks; you never send it |
| API key | sbk_0a1b2c3... | Nothing works. Delivered once |
| Granted scopes | games:read,battles:write,... | You will not know what will 403 |
| Allowed game ids | sweet-bonanza | Every battle creation fails game_not_allowed |
| Console URL + account | https://admin.platform.com | You cannot set your own webhook |
| Lobby window values | 10 min / 1 min / 5 min | You cannot change these, so you need to know them |
If any row is missing, ask before you start. Each one is slow to diagnose from the outside.
The API key
sbk_ followed by 64 hex characters. Only its hash is stored on the instance, so it is shown
once and cannot be recovered. If you lose it, the host issues a new one and revokes the old.
The tenant is derived from the key. There is no tenant header to send and no tenant field in any request body. You will see your tenant id in responses and webhooks, but you never send it.
It is a server-to-server credential covering your whole casino. Anything holding it can open battles, seat bots and read every battle you have. Proxy every call through your own backend; the tutorial shows the pattern end to end.
Check your scopes early
curl -s $BASE/games -H "Authorization: Bearer $KEY"
A 403 naming a missing scope is much easier to resolve on day one than during integration
testing. A full production integration uses games:read, battles:read, battles:write,
bots:write and viewer:mint; ask for each of them by name.
bots:write is separate from battles:write and is easy for a host to omit. If you plan to
fill lobbies with bots, which most casinos do, confirm you have it.
Verify the handover
Four calls tell you whether everything is wired:
BASE=https://slotbattle.platform.com
KEY=sbk_...
# 1. Games appear — proves the key works and the allowlist is set
curl -s $BASE/games -H "Authorization: Bearer $KEY"
# 2. A battle opens — proves battles:write and the allowlist agree
curl -s $BASE/battles -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
-d '{"game_id":"sweet-bonanza","seats_total":2,"entry_amount":"10",
"currency":"BRL","creator_player_ref":"smoke_test"}'
# 3. A viewer token mints — proves the host has a signing key
curl -s -X POST $BASE/battles/<id>/viewer-tokens -H "Authorization: Bearer $KEY"
# 4. Clean up
curl -s -X POST $BASE/battles/<id>/cancel -H "Authorization: Bearer $KEY"
If step 1 returns {"games": []}
Your allowlist is empty. That is configuration on the host's side rather than an error. Ask them to allow the games you agreed on, and note that the change takes up to 30 seconds to appear.
If step 3 returns 500 failed to mint viewer token
The instance has no viewer signing key. Battles work; live viewing does not. This is the host's to fix, so report it with that exact message.
If ws_url will not connect
Look at the port. If ws_url points at the same port as the REST API, the host has not
configured a public WebSocket base URL. The feed runs on its own port, so that URL cannot
work. Report it; you cannot fix it from your side.
What you configure yourself
Two things, both in the console, both per casino:
Your result webhook, the URL your backend listens on and the secret its requests are signed with. Without this, your backend never learns a battle ended.
Your provider credentials, if your casino has its own SoftSwiss account. Without them, bot sessions are minted under the host's casino id rather than yours.
What you cannot change
The viewer signing key, the lobby windows, recorder capacity, and when the instance is upgraded. These belong to the platform.
→ Limits
Next
- Onboarding checklist: what to do, in order
- Limits: what belongs to the host
- API overview: start integrating