Sportsbook, live casino and slots through one API integration

The usual setup: two vendors, two wallets, two balances

Most operators who run casino and sports end up with two suppliers: a casino aggregator for slots and live dealer tables, and a separate sportsbook vendor. Each one comes with its own contract, its own wallet specification, its own reporting format, its own invoice and, very often, its own deposit or minimum commitment.

On paper that is a procurement detail. In practice it is the source of most of the operational friction in a mixed casino-and-sports brand: a player who wins on a football accumulator and moves straight to a live roulette table touches two different vendors in two minutes, and the operator has to keep both wallets, both ledgers and both support channels in step.

SoftAggregator removes the second vendor. The sportsbook is a product inside the same catalogue as the casino games, reached through the same endpoint, settled through the same wallet callback and paid for from the same prepaid balance.

How the three verticals sit in one API

Everything goes through one JSON POST endpoint, /api/v1, authenticated with the same api_login and api_password. getGameList returns the whole catalogue with a normalised game_type field, so one call is enough to build the casino lobby, the live lobby and the sports entry point:

• Slots, crash, table, instant, fishing: game_type values such as slots, crash (Aviator and the rest of the crash category), table.
• Live casino: game_type: live, covering live roulette, blackjack, baccarat and game shows from Evolution, Pragmatic Play Live, Ezugi and other live studios.
• Sportsbook: game_type: sportsbook, pre-match and in-play betting across football, cricket, tennis, basketball, esports and more. A second sportsbook option is available on the same integration for operators who want a different look or market depth.

All three are opened the same way: createPlayer once, then getGame with the entry's id_hash, which returns a launch URL for an iframe. There is no separate sports SDK, no second set of credentials and no second callback URL to host.

What one wallet changes for treasury

With two vendors, the operator funds two prepayments or carries two credit lines, and has to guess in advance how much of next month's play will be sports and how much will be casino. A weekend of big football fixtures drains one balance while the other sits idle.

With SoftAggregator there is one prepaid balance. Commission is deducted from it as real-money rounds settle, at the rate of the vertical that produced the GGR: 8% for slots and casino games, 9% for the sportsbook, 11% for live casino. The balance is topped up in USDT or other supported currencies, so a single transfer funds every vertical at once, and nothing is owed on a vertical that did not produce revenue that month.

What one wallet changes for reconciliation and support

The wallet calls are identical across verticals: balance, debit and credit, sent as GET requests to the operator's callback URL, amounts in cents, a unique call_id on every movement. What differs is the rhythm, and one handler has to be written to respect all three:

• Slots and crash: a debit and a credit seconds apart, high volume, small amounts.
• Live casino: fewer rounds, larger stakes, and a betting window timed by a real dealer, so the debit answer has to be fast.
• Sportsbook: a debit at bet placement and a credit when the market settles, possibly days later; a losing ticket may never call back, and cash-outs arrive as an ordinary credit.

Because it is one handler, a fix or an optimisation made for one vertical benefits the other two. And because it is one history, getPlayerHistory returns casino rounds and sports tickets side by side, with ticket details (selections, odds, stake, payout, status) on the sportsbook entries. When a player disputes a balance, support looks in one place instead of asking two vendors for two exports.

The detailed sports-specific wallet behaviour (voids, resettlement, long-open bets) is covered on the sportsbook API integration page.

Why it matters commercially: cross-sell on the same balance

The strongest argument for one integration is not technical. A sports bettor who has just been paid out already has the money in the operator's wallet; a live blackjack table or a crash game is one click away and draws on the same balance, with no transfer between a "sports wallet" and a "casino wallet". Operators running separate vendors often end up building exactly that transfer screen, and every extra step loses players.

The same applies in reverse during the week, when fixtures are thin: casino and live tables keep the brand active, and the sportsbook is there for the weekend without a second onboarding.

Honest limits

A combined API is the right fit for operators who want sports as part of a casino brand, or casino as part of a sports brand, and want to run it without a trading team. The sportsbook is a managed product: odds, risk and settlement are handled upstream, and the operator consumes the result through the wallet. A bookmaker who wants to compile its own prices and run its own trading desk needs a raw odds feed, which is a different product.

Free-round campaigns pushed from the operator's CRM are not part of the API today; in-game free spins, bonus rounds and jackpots work normally and settle through the standard callback.

Sportsbook and live casino API — FAQ

Explore more