Slotegrator API Guide (2026)

• Slotegrator API integration is mostly about building a reliable casino platform around the API, not only calling endpoints.
• The critical flows are game catalog synchronization, game launch, lobby game launch, Wallet API callbacks, free spins, merchant limits, and self-validation.
• A production-ready integration also needs internal catalog enrichment, image handling, RTP and geo rules, monitoring, reconciliation, and support tooling.

Slotegrator API gives casino operators a practical route to a multi-provider game catalog through a single aggregator integration. The endpoint list can look straightforward at first glance, but the real implementation work is not in sending one signed request or opening one game URL. The hard part is making the integration stable enough for real-money play, provider retries, wallet mutations, free spin campaigns, lobby games, catalog changes, and certification.

This guide does not try to reproduce the private API specification. Instead, it focuses on the points that matter when a casino platform team decides what must be built around Slotegrator before production access is realistic.

The examples and terminology are based on Slotegrator API documentation version 1.4.2, dated 2025-03-11. Before launch, operators should confirm exact endpoint availability, provider configuration, currencies, optional fields, IP whitelists, certification requirements, and commercial limits with their Slotegrator integration manager.

Table of contents

• Introduction
• Game catalog and synchronization
• Game launch and lobby games
• Wallet API callbacks
• Free spins creation flow
• Merchant limits
• Self-validation integration test
• What the API does not cover
• Conclusion

Introduction

Slotegrator sits between the casino backend, game providers, and live game sessions. The casino backend requests game data and launch URLs from Slotegrator, while Slotegrator sends Wallet API callbacks back to the casino whenever a player balance has to be checked or changed.

That separation is important. Slotegrator can abstract providers and launch flows, but the casino remains responsible for player accounts, balances, wallet ledgers, bonus policy, responsible gaming rules, reporting, monitoring, and customer support. In a seamless wallet model, the operator's backend is the source of truth for money.

At a high level, the integration has two directions:

All sensitive requests are signed. The signing layer must be implemented carefully, but it should not dominate the platform design. Once authentication works, the larger engineering questions are idempotency, wallet locking, catalog quality, operational visibility, and whether the system can pass Slotegrator validation without special-case hacks.

The practical architecture looks like this:

flowchart LR
  Player["Player"] --> Frontend["Casino frontend"]
  Frontend --> Backend["Casino backend"]
  Backend --> SG["Slotegrator API"]
  SG --> Provider["Game provider"]
  Provider --> Player
  SG --> WalletAPI["Casino Wallet API"]
  WalletAPI --> Ledger["Wallet ledger"]
  Ledger --> Backend

The launch flow is visible to the player, but the Wallet API flow is what decides whether the product can safely handle real money.

Game catalog and synchronization

The game catalog should be treated as a synchronized data source, not as a static file and not as something the frontend calls directly. The casino backend should fetch /games, store the raw payload, normalize it into the platform's own game model, and expose a product-specific lobby API to the frontend.

The fields that matter most operationally are game UUID, name, provider, type, technology, mobile support, lobby support, free spin support, and image URL. The exact model should also include internal status, market visibility, category mapping, search metadata, manual overrides, and sync timestamps.

A practical sync pipeline usually has these stages:

flowchart TD
  Sync["Scheduled catalog sync"] --> Fetch["Fetch /games"]
  Fetch --> Raw["Store raw Slotegrator payload"]
  Raw --> Normalize["Normalize internal game model"]
  Normalize --> Images["Download and cache images"]
  Normalize --> Rules["Apply product and market rules"]
  Rules --> Lobby["Expose internal lobby API"]
  Rules --> Search["Update search and filters"]

Game images need special attention. Slotegrator may provide image URLs, but the platform should download and cache those assets instead of relying on third-party hotlinks in the player-facing lobby. A controlled image pipeline lets the casino resize images, serve them from its own CDN, prevent broken lobby tiles, and replace low-quality images later without changing the integration contract.

Catalog sync should be observable. Operators need to know when the last successful sync happened, how many games were added or removed, which providers changed, which images failed to download, and whether any provider suddenly disappeared from the feed. A quiet catalog failure can look like a frontend problem while the real issue is data freshness.

Game launch and lobby games

Game launch is the most visible part of the integration, but it should still be treated as a backend-controlled session flow. The casino frontend should ask the casino backend to launch a game. The backend validates the player, currency, market, game availability, device, and session policy, then calls Slotegrator to create the launch URL.

For regular games, the main production concerns are:

• Store an internal session before calling Slotegrator.
• Do not treat launch URLs as reusable static URLs.
• Validate that the game is active for the player's market and currency.
• Keep the player's return URL under platform control.
• Store launch mode, game UUID, provider, device, currency, and player ID for later reconciliation.

Lobby games add another step. Some games require lobby data before launch, especially live casino and table-style products. In those cases the platform needs to call the lobby endpoint, let the player select the correct table or lobby item where applicable, and pass the selected lobby data into the launch flow.

The common mistake is assuming that all games behave like slots. A launch implementation that works for regular slot games can still fail for lobby games if lobby data is missing, stale, or not connected to the player's selected table. The catalog should therefore expose whether a game has lobby support, and the frontend should route those games through the correct flow.

There is also a subtle session issue: some provider flows can produce transactions with a different game UUID under the same session, or with related round/session identifiers that do not map neatly to one visible game tile. The backend should store provider context without assuming that one session always equals one game forever.

Wallet API callbacks

The Wallet API is the most important part of the integration. It is where Slotegrator asks for balance and sends balance-changing actions. The callbacks that must be handled are:

The correct implementation model is a ledger. Directly updating a balance column from callback code is not enough for production. Every accepted callback should create or reference a durable transaction record with external transaction ID, internal transaction ID, player, wallet, amount, currency, action, game UUID, session ID, round ID where available, raw payload metadata, and final response.

Three rules matter more than almost anything else:

1. Idempotency must be based on Slotegrator's external transaction ID, not on session ID or round ID.
2. Wallet mutation must be serialized per wallet through database locks, advisory locks, or an equivalent wallet processing model.
3. Duplicate callbacks must return the original stored response instead of mutating the wallet again.

balance looks simple, but it must still read the committed wallet state with the precision expected by the integration. bet must handle insufficient funds as a business response, not as a generic server failure. win should be recorded even when the amount is zero, because it can carry round state. refund should be safe when the referenced bet is missing or delayed. rollback should process only the transactions Slotegrator explicitly asks to roll back, not everything that appears to share the same round.

The platform should also store enough data for finance and support teams. If a player disputes a round, support should be able to search by player, game, external transaction ID, internal ledger ID, session ID, and round ID. If this data only exists in logs, reconciliation will become painful quickly.

Free spins creation flow

Free spins should be integrated as a bonus product flow, not only as an API call. A free spin campaign affects eligibility, bonus reporting, wallet callbacks, support workflows, and player communication.

The working flow has four parts:

The critical implementation detail is that free spin setup depends on game and currency configuration. A bet option that works for one game or currency may not work for another. The platform should not hardcode bet IDs globally. It should cache available free spin bet structures per game and currency, then validate campaign creation against that data.

The casino also needs its own free spin campaign model. Store campaign ID, player, currency, game UUID, quantity, validity window, selected bet option, current status, Slotegrator state snapshots, and related Wallet API transactions. Free spin wins can appear through the same wallet callback surface, so bonus accounting has to be connected to wallet processing.

Common failure points are reusing campaign IDs, creating campaigns for games without free spin support, ignoring validity semantics, and treating free spin wins as ordinary cash activity without checking the casino's bonus rules.

Merchant limits

Slotegrator exposes merchant limits through /limits and free spin limits through /limits/freespin. These endpoints are easy to overlook, but they are useful for operational readiness because they show remaining limit capacity by currency and the providers attached to that limit.

The regular merchant limits response contains an amount, currency, and provider list. The free spin limits response contains remaining quantity, currency, and provider list. In practice, this tells the platform which provider groups are connected to each merchant-level limit and how much room remains for that currency.

The exact business meaning of those limits should be confirmed with Slotegrator, because it can depend on commercial setup. A reasonable way to describe the value in the platform is: these limits indicate the remaining merchant capacity for provider activity in a specific currency, and they should be monitored before launching or scaling traffic.

Operationally, the casino should:

• Fetch and display limits in an internal admin or operations view.
• Track changes over time, especially for active currencies and high-volume providers.
• Alert when limits become low enough to affect player activity or free spin campaigns.
• Use provider lists to understand which games can be affected by a particular limit.
• Confirm with Slotegrator what happens when a limit is exhausted.

For free spins, /limits/freespin is especially relevant before creating campaigns at scale. A promotion can look valid in the casino backoffice but still fail operationally if the merchant free spin limit is insufficient for the selected currency/provider group.

Self-validation integration test

The /self-validate flow is not just a convenience test. It is a certification gate. Slotegrator uses it to verify that the platform's Wallet API changes balances correctly across multiple callback scenarios.

This test matters because the Wallet API is where production risk lives. If balance, bet, win, refund, or rollback behavior is wrong, the platform can double-debit players, double-credit wins, reject valid provider retries, or create reconciliation mismatches. Slotegrator needs to see that the wallet behaves deterministically before issuing production credentials.

The platform should prepare a dedicated test wallet and currency setup for self-validation. One important detail is decimal precision: the test currency and wallet balances must support four digits after the decimal point, because that is the precision Slotegrator expects during validation. If the platform stores only two decimal places for the test currency, validation can fail even when the high-level logic looks correct.

Before running self-validation, the team should verify:

• Signed inbound callbacks are accepted only when valid.
• balance returns the expected current balance.
• bet decreases balance once and only once.
• win increases balance once and only once.
• refund restores or compensates correctly.
• rollback reverses exactly the listed transactions.
• Duplicate callback delivery returns the original stored response.
• Amounts are stored and returned with the required precision.
• Internal ledger entries can be inspected by engineering and support.

Without a successful self-validation run, the platform should not expect production keys. Treat this as an integration milestone, not as a last-minute QA task.

What the API does not cover

Slotegrator API covers the core integration path, but a casino lobby needs more than endpoint connectivity. Some missing or weak areas could theoretically be handled at API level, but in practice operators often need to solve them inside their own platform.

The first gap is game imagery. Slotegrator provides images for games, and those images should be downloaded and cached as part of catalog sync. However, many operator teams find that the provided images are outdated, inconsistent, or not attractive enough for a modern casino lobby. A production casino often needs its own image curation process, manual replacements, CDN variants, and design QA for lobby tiles.

The second gap is provider identity data. Provider names may exist, but the platform may still need stable internal provider IDs, provider logos, provider images, display names, and frontend ordering. Those assets are usually collected and maintained manually or from third-party sources.

The third gap is RTP data. Not every game has complete RTP information in the API feed. When RTP is provided separately through non-standard Excel files, the platform team has to parse, normalize, review, and import it manually. That creates an operational process outside the API integration.

The fourth gap is geoblocking. A real casino needs to know which games or providers are restricted in which countries or markets. If the API does not provide standardized game/provider geo availability, the operator must maintain those restrictions manually, often from separate spreadsheets or commercial documents.

These gaps do not make the API unusable, but they change the project scope. A complete integration is not finished when launch and callbacks work. It also needs content operations, data enrichment, compliance rules, support tooling, monitoring, and reconciliation workflows.

Conclusion

Slotegrator API can be a practical path to multi-provider casino integration, but the implementation should be planned as a platform capability rather than a thin connector.

The critical work is clear: synchronize the catalog, download and cache images, support lobby game launch, implement a ledger-based Wallet API, handle idempotency and wallet locking, build the full free spin flow, monitor merchant limits, and pass /self-validate with the precision Slotegrator expects.

The API does not remove the need for product data operations. Operators still need to enrich game imagery, provider assets, RTP data, and geo restrictions. Teams that plan for those gaps early will have a cleaner launch path than teams that discover them after the first provider catalog sync.