Sportsbook API integration: the project, step by step

Pick the integration model before the provider

Operators often compare sportsbooks on sports and markets and only later discover they were comparing different kinds of product. There are three models, and they put the work in very different places.

• Odds feed (data API). You receive prices and results and build everything else: front end, bet acceptance, risk, settlement. Maximum control, maximum team.
• Managed sportsbook with seamless wallet. The sportsbook provider runs pricing, bet acceptance, risk and settlement; you open it for a player and answer wallet calls. This is the model our sportsbook follows.
• Full white-label. The provider also runs the player account and cashier. Fastest, least control, and effectively a platform decision.

Our sports betting API page describes the product; this page is about the project of plugging it in. If you want the branded, front-end view instead, see white-label sportsbook.

Step 1 — Player identity and launch

The sportsbook must know who the player is before it can show a balance. In our catalogue the sportsbook is an entry in getGameList with game_type: sportsbook, opened with the same launch call as any game, for a player created with createPlayer.

A sportsbook session begins with a balance call to your wallet. If your callback URL is not set, or does not answer for that username, the session cannot start — even though casino games may seem to open, because they only reach the wallet on the first bet. Make the balance answer the first thing you test. Send the player’s currency and, for real-money use, the country on the launch; the currency is fixed per player once created.

Step 2 — The wallet: stakes, payouts and the long gap between them

The calls are the ones documented for the whole catalogue: balance, debit and credit, sent as GET requests to your callback URL, amounts in cents, a unique call_id on every money movement and a round_id tying them together. What sports changes is the timeline.

• Stake at placement. A debit when the bet is accepted. Answer fast: a betslip on an in-play market has a short acceptance window and prices move.
• Payout at settlement. A credit when the market settles, which can be minutes or days later. Your ledger must hold open bets without treating them as errors.
• Lost bets may never call back. A losing bet can end without any credit. Do not wait for one to close the bet in your books; reconcile against the round history instead.
• Credits without a matching debit in the same session. The documentation already warns that a credit can arrive with no matching debit; in sports the matching debit may simply be days old. De-duplicate on call_id alone.
• Rollbacks. Flagged rb=1 and processed like a normal debit or credit.

The signature rules — key = md5(timestamp + salt_key), a 30-second window, HTTP 200 always with errors in the body — are on the seamless wallet page and in the documentation.

Step 3 — Settlement, voids, resettlement and cash-out

These four events are where sportsbook integrations lose money quietly, because each one moves balance after the operator thinks the bet is finished.

• Settlement. The normal case: a credit for the payout, or nothing for a loss.
• Void. A cancelled event or a palpable error returns the stake. Expect a credit equal to the stake, or a rollback of the original debit.
• Resettlement. A result corrected after settlement — an overturned goal, a disqualified runner — can reverse a payout. Your wallet must accept a correcting movement on a bet it already closed, and your support team needs a way to explain it to the player.
• Cash-out. Where the sportsbook offers it, an early cash-out closes the bet with a credit before the event ends. It is an ordinary credit to your wallet; the only special thing is that no later settlement credit follows.

Cash-out is part of our sportsbook API on the markets that support it, and reaches your wallet as a plain credit.

Step 4 — Bet history and reconciliation

Long-open bets make reconciliation the core of the project, not an afterthought. getPlayerHistory returns one player’s rounds, newest first, with total bet, total win, net result, number of wallet legs and a rollback flag, filterable by date and paged up to 500 rows.

It is a record of money movements, not of betslips: selections, odds and market names are not in it. For the player-facing “my bets” view, the sportsbook front end is the place; for your finance team, compare the history against your own ledger daily and flag any bet open longer than its event should allow. Your own callback log, which you hold in full, is the natural backbone for that reconciliation.

Step 5 — Risk and responsible gambling

In the managed model, pricing, liability and bet acceptance are run by the sportsbook, as our sports betting page describes. That removes the trading desk from your project, not your obligations.

Deposit limits, loss limits, self-exclusion and cool-off periods stay on your platform because you hold the balance. The cleanest control point is your debit handler: a player who is excluded or over a limit gets error: 1 and the stake is refused, whichever product they are in. Apply the same logic to casino and sports and you have one place to audit.

Step 6 — CRM and bonus integration

Most sportsbook CRM needs are met by listening to the wallet. Every stake and payout reaches your platform with an amount, a player, a round and a timestamp, which is enough for turnover-based rewards, loyalty points, win-back triggers and VIP tiering.

Bonus money comes in two kinds. A cash bonus you credit to the player’s balance is spent through the normal wallet and needs nothing special. A free bet that must exist inside the betslip, an odds boost or an acca insurance relies on the sportsbook’s own promotion tooling: scope those at the start of the project and agree them in writing before marketing builds a campaign around them.

Where this leaves the provider comparison

Once the project is clear, the sportsbook comparison becomes sharper: who runs the risk, how voids and resettlements reach the wallet, whether cash-out exists on your markets, and whether bonus mechanics are available through the provider. For the vendor side of that decision, our SOFTSWISS vs EveryMatrix comparison covers two full-stack suppliers, and the casino game aggregator API page explains how sports and casino share one integration.

Sportsbook API integration — FAQ

Sources and last update

This page describes integration practice. Statements about SoftAggregator come from our public API documentation and our published sports betting pages; general sportsbook behaviour (voids, resettlement, cash-out) is described as it works across the industry. The catalogue and currencies evolve continuously; the up-to-date list is always in the API.

• SoftAggregator API documentation — getGameList (game_type sportsbook), createPlayer, getGame, getPlayerHistory, wallet callbacks and signature. Checked 24 September 2026.
• SoftAggregator sports betting API and white-label sportsbook pages. Checked 24 September 2026.

Last reviewed: 24 September 2026. Questions about a specific integration: [email protected].

Explore more