Slots are the largest content category in almost every online casino, and the API that delivers them looks deceptively simple: list some games, open one, settle the money. The complexity sits in the details — how a launch URL is minted, which wallet model the studio expects, what metadata you are allowed to display, and how bonus and jackpot mechanics reach your ledger. This guide walks those pieces in the order you meet them, with illustrative examples against deliberately generic endpoints. For the specifics of our own implementation, see the iGaming API developer hub.
What a slots API is
A slots API is the contract between your platform and the parties that produce slot games. It covers three questions: what games exist and what they are like, how a specific player opens a specific game, and how each spin's money moves. Everything else — bonuses, jackpots, reporting — is layered on top of those three.
An aggregated slots API answers those questions once for many studios. A direct studio API answers them for one. The shapes are broadly similar either way, which is why an integration built cleanly against one is usually not hard to point at another.
How slot content is delivered
Six surfaces cover essentially every slots API in the market. Names differ; shapes rarely do.
Slot catalog
A normalised list of slot games with stable identifiers plus studio, theme, reels, lines, RTP, volatility, max win and per-jurisdiction availability.
Session launch
A server-side call exchanging a player, game, currency and language for a short-lived launch URL that your client renders in an iframe or opens directly on mobile.
Wallet contract
Endpoints on your server that the provider calls to read a balance, debit a spin, credit a win and roll back a failed round.
Free spins
Campaign endpoints that grant a number of spins at a fixed bet on named games for a named player, with an expiry and a way to query remaining spins.
Jackpot feeds
A near-real-time feed of current pooled jackpot values so your lobby can display live tickers, plus win notifications when a pool drops.
Reporting
Per-game, per-studio and per-player aggregates you reconcile your own ledger against on a fixed schedule.
Note the two directions of traffic. You call the provider for catalog, session and bonus work; the provider calls you for wallet work. Those are different security models and different failure modes, and keeping them separate in your architecture from day one saves a great deal of confusion later. The casino games API guide covers the general integration flow in more depth.
Game launch
Launch is a server-side exchange: your back end knows the authenticated player, picks the currency, language and jurisdiction, and receives a short-lived URL. The browser only ever sees that URL, rendered in an iframe on desktop or opened directly on mobile.
// Illustrative example — endpoints are generic placeholders.
// Session creation is always server-side; credentials never reach the browser.
POST /v1/slots/sessions HTTP/1.1
Host: api.example-aggregator.com
Authorization: Bearer $SLOTS_API_KEY
Content-Type: application/json
{
"gameId": "studio-x:book-of-example",
"playerId": "u_84f21c", // stable internal identifier
"currency": "EUR", // ISO 4217
"language": "en", // ISO 639-1
"mode": "real", // or "demo" — demo never touches the wallet
"device": "mobile",
"jurisdiction": "MT",
"returnUrl": "https://your-casino.example/lobby"
}
// 200 OK
{
"sessionId": "s_9f2c41ab",
"launchUrl": "https://games.example-aggregator.com/launch?t=eyJhbGci...",
"expiresAt": "2026-01-14T10:32:00Z"
}A few details save time later. Pass a stable internal player identifier rather than an email or anything you may want to change. Treat launch URLs as single-use and short-lived, and re-mint rather than cache them. Support demo mode through the same code path so QA can exercise the lobby without touching the wallet. And always supply a return URL so a player leaving a slot lands back in your lobby rather than on a blank page.
Wallet models: seamless vs transfer
Seamless — also called single wallet — is the default in most modern integrations. The player's balance never leaves your ledger; the provider calls your endpoints in real time for each spin. It gives the player one balance and gives you a single source of truth, at the price of running a highly available, low-latency, strictly idempotent wallet service.
Transfer wallets move funds into a provider-held balance before play and back afterwards. They lower the availability requirement on your side, because a slow response no longer interrupts a spin, but they introduce a visible second balance, transfer failures to reconcile and a worse player experience. Some studios and some jurisdictions still require them, so it is worth knowing which model each provider on your shortlist supports.
// Illustrative example — a spin debit callback the provider sends to YOUR server.
POST /wallet/debit HTTP/1.1
Host: your-casino.example
X-Signature: 9c1f... // HMAC of the raw body; verify before parsing
Content-Type: application/json
{
"transactionId": "tx_7731aa02", // idempotency key — never debit twice
"roundId": "rnd_55c1",
"sessionId": "s_9f2c41ab",
"playerId": "u_84f21c",
"gameId": "studio-x:book-of-example",
"amount": 1.00,
"currency": "EUR",
"bonusSpin": false
}
// 200 OK — business outcomes are successful responses carrying a status.
{ "status": "OK", "balance": 148.50 }
// 200 OK — not a 4xx: the provider needs to show the player a clean message.
{ "status": "INSUFFICIENT_FUNDS", "balance": 0.40 }Three properties matter more than anything else in a seamless implementation. Idempotency: enforce the transaction ID with a unique database constraint, so a retried debit returns the original outcome rather than charging twice. Atomicity: write the balance change and the ledger row in a single transaction. Speed: respond in milliseconds and queue anything slow, such as bonus evaluation or analytics. Rollbacks deserve particular care, because they can arrive for a round you never recorded — treat that as an idempotent no-op rather than an error.
RTP, volatility and other metadata
Slot metadata is what makes a lobby usable: players filter by theme, volatility and feature, and regulators in several markets require RTP to be displayed. All of it originates from the studio and is confirmed during certification, so treat it as data you store and display rather than data you compute.
// Illustrative example — a normalised slot catalog record.
{
"id": "studio-x:book-of-example",
"name": "Book of Example",
"studio": "Studio X",
"category": "slots",
"theme": ["adventure", "egypt"],
"reels": 5,
"rows": 3,
"paylines": 10,
"rtp": 96.12, // set by the studio, confirmed at certification
"rtpVariants": [96.12, 94.05], // some titles ship configurable versions
"volatility": "high",
"maxWinMultiplier": 5000,
"minBet": { "EUR": 0.10 },
"maxBet": { "EUR": 100.00 },
"features": ["free_spins", "expanding_symbols"],
"jackpot": null,
"mobile": true,
"demoSupported": true,
"jurisdictions": ["MT", "CW", "ZA"],
"certifiedFor": ["MT"]
}Two practical points. First, some titles ship multiple configurable RTP versions, and which one is active for your brand is a commercial and regulatory decision — record the version actually enabled for you, not the best-case figure. Second, treat the game identifier as an opaque string and never derive meaning from its format. Refresh the catalog on a schedule, persist a normalised copy with your own merchandising fields, and serve the lobby from your copy so page loads stay fast and the lobby survives a provider blip.
Free spins and jackpot feeds
Free spin APIs generally follow the same shape: a call that grants N spins at a fixed bet level on a named set of games to a named player, with an expiry, plus calls to query remaining spins and to cancel an unused award. The spins themselves settle through the ordinary wallet callbacks, normally flagged so you can attribute the cost to the campaign instead of to regular play. Make sure your ledger keeps that flag — retrofitting bonus attribution after the fact is unpleasant.
Jackpot feeds are read-only and frequently polled or streamed. They supply current pool values so your lobby can show a live ticker, and win events when a pool drops. Cache aggressively and render optimistically: a ticker that ticks smoothly from a cached value looks better than one that jumps on every poll. Jackpot wins themselves still arrive as ordinary wallet credits, so no special settlement path is needed.
Certification and jurisdiction considerations
Every slot in a regulated market must be certified for that market, and the certified build is not always identical to the one available elsewhere. Your catalog therefore needs both an availability list and a certification list, and launch must be validated server-side against the player's jurisdiction. Hiding a tile in the lobby is a UI decision, not a compliance control.
Beyond content, markets impose their own rules: mandatory RTP display, spin-speed and autoplay restrictions, session reminders, deposit and loss limits, reality checks and regulator reporting. Some of these are enforced by the game build, some by your platform, and the split differs by jurisdiction. Confirm which side owns each control in writing before launch, and take local legal advice — an aggregator supports your licence conditions but does not provide a licence on your behalf.
Evaluating a slots API provider
Whichever names end up on your shortlist, evaluate them the same way. Each criterion below can be checked before you sign anything.
Catalog fit, not catalog size
Ask whether the slot studios your market actually plays are available in your jurisdictions. A large headline number that excludes your top ten titles is worth nothing.
Studio coverage and release cadence
New slot releases drive retention. Ask how quickly new titles from existing studios appear and how new studios are onboarded.
Launch latency
Time from session request to a playable game is a conversion metric. Measure it yourself, from your own regions, during your own peak hours.
Mobile behaviour
Most slot volume is mobile. Check portrait handling, in-app browser behaviour, resume after a dropped connection, and whether the return URL works reliably.
Documentation quality
Public, current documentation is the best available proxy for how the integration will feel. Vague docs before a contract rarely improve after one.
Wallet semantics in writing
Duplicate transaction IDs, rollbacks, timeouts and disconnected rounds. Get the exact behaviour documented before you build against it.
Sandbox before signature
A provider confident in its slots API lets your engineers spend a day in it first. Access gated behind a signed contract is itself information.
Jurisdiction controls
Content must be restrictable per market at the server, not just hidden in the lobby, and the provider should support the reporting your licence requires.
Aggregator vs direct studio integrations
A direct studio integration gives you the closest commercial relationship and the earliest access to that studio's releases. It also gives you that studio's wallet contract, that studio's certification paperwork, that studio's reporting format and that studio's on-call escalation path. Multiply by twenty studios and the engineering cost stops being about slots at all.
An aggregator collapses that into one integration: one authentication scheme, one wallet contract, one catalog shape, one reporting surface, and new studios added without new engineering. The trade-off is a layer between you and the studio, which matters most where a single studio drives a large share of your revenue. That is why most operators end up hybrid: direct where volume clearly justifies it, aggregated for everything else. Our casino game aggregator guide works through that decision, and the Hub88 alternatives comparison covers how the main aggregation vendors differ in shape.
Frequently asked questions
What is a slots API?
A slots API is the interface an operator's back end uses to list slot games, read their metadata, launch a game session for a specific player and settle the bets and wins that session produces. In an aggregated setup one slots API covers slot content from many studios behind a single authentication scheme and a single wallet contract.
What is the difference between a seamless and a transfer wallet?
In a seamless (single) wallet the player's balance stays in your system and the game provider calls your endpoints in real time to debit a bet and credit a win. In a transfer wallet, funds are moved into a provider-held balance before play and transferred back afterwards. Seamless is the more common model today because the player never sees two balances, but transfer wallets still appear with some studios and in some jurisdictions.
Where do RTP and volatility values come from?
They are properties of the game itself, set by the studio and confirmed during certification, and are exposed to you as catalog metadata. Some slots ship with more than one configurable RTP version, in which case the version enabled for your brand and market is what your catalog record should reflect. Never derive or recalculate these values yourself.
How do free spins work through a slots API?
Free spin rounds are usually created by a separate call that awards a number of spins at a fixed bet level on specific games for a specific player, with an expiry. The spins are then played inside the game and settled through the normal wallet callbacks, typically flagged so that you can attribute the cost to the campaign rather than to normal play.
Do I need certification to offer slots?
Games must be certified for each regulated market they run in, and your platform must hold the appropriate licence. The studio and the aggregator handle game-level certification; the licence and the market-by-market content restrictions are your responsibility as the operator. Take local legal advice before going live in any jurisdiction.
Is an aggregator API better than integrating studios directly?
It depends on volume. Direct integrations can be worth the engineering where a single studio drives a large share of your revenue and you want the closest possible commercial relationship. For everything else, one aggregated integration means one wallet contract, one certification conversation and one place to add new studios, which is why most operators run a hybrid.
The examples above are deliberately generic so they apply to any provider. For our exact endpoints, SDKs and wallet contract, see the iGaming API developer hub, or talk to our team about your markets and studio requirements.
Try it in the sandbox
Free sandbox access, full documentation and SDKs — no credit card required.