SlotBattle
SlotBattle runs slot battles. Several players buy the same bonus on the same slot game at the same time, every seat is recorded as video, and an audience watches all of them side by side while the spins land. When the last seat finishes, SlotBattle reports each seat's multiplier to your backend and the battle ends.
SlotBattle is a microservice you integrate, not a product your players log into. Your casino owns the player, the wallet, the balance and the settlement. SlotBattle owns the battle: who is seated, what is being recorded, what the audience sees, and what each seat scored.
What it does
- Runs the lobby. A battle opens with a fixed number of seats, an entry amount and a currency. Players take seats and bots can fill the rest. The battle starts on its own when the last seat is taken.
- Records every seat. Each seat gets its own headless browser playing the real game, captured to HLS video and uploaded as it is produced, so the audience sees a seat's spins while that seat is still spinning.
- Broadcasts the battle live. A WebSocket feed carries lobby changes, spin starts and new video segments to every connected viewer.
- Reports the result. One signed webhook per battle carries each seat's outcome and multiplier to your backend, with durable, idempotent delivery.
What it does not do
The boundary below decides how you integrate.
| SlotBattle | Your backend |
|---|---|
| Seats, lobby, battle lifecycle | Player identity, sessions, KYC |
| Recording, HLS, the live feed | Wallet, balance, entry debit |
| Each seat's raw multiplier | Who won, what they get paid, settlement |
| Which games can be played | Which players may play them |
SlotBattle emits raw events keyed by seat and has no concept of winning. Translating
multiplier: 138.4 into "player X won R$ 1.384,00" is your backend's job. Payout rules vary
by casino and by jurisdiction, and SlotBattle holds none of them.
How you get it
The platform runs the instance. You receive a base URL, a tenant id and an API key, and integrate against them. There is no infrastructure on your side and nothing to deploy.
Some things are yours: your result webhook, your provider credentials, your console users, the battles you open. Others belong to the platform: the viewer signing key, the lobby windows, recorder capacity, upgrade timing. Check the split before designing around a value you cannot change.
What you receive lists what to have in hand before writing code. Tenancy covers the split in full.
Where to go next
- New to the system? Start with Battle lifecycle. The rest of these docs assume it.
- Just handed credentials? What you receive, then the onboarding checklist.
- Integrating a casino backend? API overview, then the tutorial, which builds a working casino against a real instance.
- Operating the console? Admin console.