Skip to main content

Onboarding checklist

In order. Each step unblocks the next.

Before writing code​

  • Collect the handover items. → What you receive
  • Confirm your scopes, especially bots:write, which is separate from battles:write and easy for a host to omit.
  • Confirm the allowed games. Ask for id values rather than display names; id is what the API takes.
  • Ask for the lobby window values. You cannot change them, and your UI has to be accurate about how long a lobby stays open.
  • Store the API key in a secrets manager, not in a repository and not in a front-end environment file.

Set up your side​

  • Build a server-side proxy. Every SlotBattle call goes through your backend, and the API key never reaches a browser.
  • Stand up a webhook endpoint that verifies X-Slotbattle-Sign as HMAC-SHA256 over the raw body, with a constant-time comparison. → Webhooks
  • Configure the webhook in the console: URL and secret together, since half-filled is refused at the write.
  • Configure your provider credentials, if your casino has its own SoftSwiss account. Otherwise bot sessions are minted under the host's casino id.
  • Make the endpoint idempotent on battle_id + status. Delivery is at-least-once.

Verify the connection​

  • GET /games returns a non-empty list
  • POST /battles returns 201
  • The battle response includes a ws_token. If it is absent, the host has no signing key
  • A WebSocket connection to ws_url gets 101 Switching Protocols
  • Cancel the smoke-test battle so it does not sit in your lobby list

Build the integration​

  • Catalog. Render GET /games. rtp: 0 means the game has no profile rather than an RTP of zero, and status: planned means not ready to sell.
  • Open a battle. Decide whether to supply creator_game_url. Omitting it leaves the creator's seat unable to play, and the battle will not start. → Battle lifecycle
  • Seat players. Handle 409 for a player already in another active battle: one active battle per player, per casino.
  • Bots. Only the creator may call them, and if you name them you must supply at least as many entries as empty seats.
  • Live view. Mint a viewer token per viewer, connect with the subprotocol header, and handle the eight public event types. → WebSocket
  • Settlement. From the webhook, never from a WebSocket frame.

Handle the edges​

  • 503 unavailable. The instance is at capacity. Retry with backoff and jitter; this is the one routinely retryable error.
  • Token expiry. Viewer tokens live 15 minutes. Re-mint on reconnect and when a page sits open past that.
  • No replay on the socket. A viewer joining mid-battle sees nothing that already happened. Render from a fetched snapshot, then apply events.
  • ok: false seats. A completed battle can contain a failed seat. Check ok per seat before settling anything.
  • battle.failed. The recording broke or a window expired. Decide your refund policy; SlotBattle has none.
  • Creator leaves means the battle is cancelled. Make sure your UI says "cancel", not "leave", for the creator.

Before going live​

  • The webhook endpoint is reachable from the instance, verified with a real battle rather than a local tunnel
  • Signature verification rejects a tampered body, tested rather than assumed
  • Settlement is idempotent under duplicate delivery
  • A late-joining viewer renders a correct lobby
  • Nothing logs game_url or creator_game_url, which are live session URLs
  • The API key is not in any client bundle. Grep the built assets for sbk_
  • You know who to contact when a 500 failed to mint viewer token appears

Ongoing​

  • Ask the host for their upgrade schedule, since deploys can fail battles in flight
  • Ask how you learn about signing-key rotations. Handled correctly they are invisible; handled without a window they drop your audience
  • Monitor your own webhook success rate. The host retries, but you should notice

Next​