Where integration time really goes
Ask a developer how long it takes to connect a game aggregator and you will hear "a few days". Ask the operator how long it took from first email to first real bet and the answer is often weeks. The difference is everything that happens before a developer can touch the API: discovery calls, a proposal, contract drafts going back and forth, an integration fee that has to clear, then sandbox keys, then a separate request for production keys.
We cut out that front end. Our documentation can be read before you apply. There is no contract negotiation and no fee to pay before access. Once your account is approved, credentials and test credit are in your back office, and the test credit works on the real API, so there is no sandbox-to-production switch later.
Before you start: what you need on your side
- A player wallet. Our API is a seamless wallet: balances live on your platform. If you already have one, you are most of the way there. If not, build or buy that first, since no aggregator can shorten it for you.
- A public HTTPS endpoint that can receive our wallet callbacks and answer quickly.
- A list of your player currencies and the countries you will serve, because both affect which games can launch.
Step 1: get credentials
Request access on the API key page. After approval you will find your login, password and a secret salt in the operator back office. Set the URL where we should send wallet callbacks. That is the only configuration needed to begin.
Step 2: confirm your currencies
Call the currency method before anything else. It tells you which player currencies are enabled for your account. Skipping this step is the most common reason for a launch that fails with no obvious cause: the player was created in a currency the game cannot accept.
Step 3: pull the catalog
Request the game list. Every title comes with a stable identifier, a thumbnail, its studio and a normalized game type. Build your lobby sections from that type field (slots, live, crash, table, sport) rather than from studio labels, which differ in style from one studio to the next. Store the identifiers; you will pass them back to launch games.
Step 4: create a test player
Register one player with a username and currency. The currency is fixed for that player from then on, so pick it deliberately.
Step 5: write the callback handler
This is the only part that needs real care. We will call your endpoint with three actions:
- balance when a session opens,
- debit for each bet,
- credit for each win.
Answer every call with HTTP 200 and a JSON body containing the new balance, with amounts as integers in minor units (2.50 becomes 250). Report problems such as insufficient funds through an error code in the body, not through an HTTP error. Validate the signature on every request and de-duplicate on the transaction id so that a retried call never moves money twice.
Two rules prevent most support tickets. First, never reject a callback because you do not recognize its type field; treat it by its action. Second, accept a credit that has no matching debit. In-game free spins, bonus rounds and jackpots pay out exactly that way, and a handler that refuses them leaves players unpaid. Rollbacks arrive with a flag and are processed as an ordinary debit or credit.
Step 6: launch a game
Request a launch URL for one slot, sending the player, the game identifier, the device type and the player's country. Open the URL in an iframe, spin with test credit, and watch the debit and credit arrive at your endpoint. Then check the player's round history to confirm the bet and win match what your ledger recorded.
A realistic timeline
For a team that already runs a wallet, steps 2 to 6 fit into a single working day; a first real game round on day one is a realistic goal. Turning that into a production lobby, with the full catalog, live casino, sport, mobile launches, languages and demo mode, is typically about a week of work. Teams without a wallet should add whatever building one takes them.
Adding live casino or the sportsbook does not restart the project. Both appear in the same game list, open with the same launch call and settle through the same callbacks, so they are front-end work only. Our sportsbook API page explains the few sport-specific points, such as bets that settle long after they are placed.
Going live
When testing is done, load prepaid credit (100 USD minimum per top-up) and switch real players on. Commission is deducted from that credit as real-money rounds settle. Running more than one brand? Each extra site gets its own credentials and callback URL on the same account, with no new integration.
For the complete list of methods and fields, see the casino game aggregator API overview. For costs, see pricing and the free casino API explainer. To compare onboarding speed with other vendors on like-for-like terms, use the comparison hub.
Frequently asked questions
How quickly can I integrate a casino API?
A team that already runs a player wallet can reach a first real game round within one working day after receiving credentials. A full production lobby with live casino and sport typically takes about a week.
Is there a separate sandbox?
No separate sandbox is needed. Approved accounts get test credit on the live API, so the environment you test on is the one you go live on.
What slows integrations down most often?
Contract rounds and upfront fees, then two technical issues: player currencies that are not enabled, and wallet handlers that reject bonus wins arriving without a matching bet.
Does adding live casino or sports betting take longer?
Only on the front end. Live tables and the sportsbook use the same launch call and the same wallet callbacks as slots.
Do I need to build a wallet first?
Yes. The API is a seamless wallet, so player balances must live on your platform. If you have no platform, our white-label casino service includes one.