Integration Overview

The R-Live game platform is a B2B service that provides games to operators (casino sites) through an API. This page summarizes the integration components, terminology, and operating modes at a glance.

Components

An integration has three channels. The operator needs to implement two of them — ① calling the Operator API and ② receiving wallet callbacks — while ③ the game screen is provided by the platform.

 ┌──────────────────────┐   ① Operator API (HTTPS, signed)   ┌──────────────────────┐
 │                      │ ─────────────────────────────────▶ │                      │
 │   Operator server    │   POST /operator/v1/launch, etc.   │ R-Live game platform │
 │    (site backend)    │                                    │                      │
 │                      │ ◀───────────────────────────────── │                      │
 └──────────────────────┘  ② Wallet callback (HTTPS, signed) └──────────────────────┘
            ▲               POST {wallet_base_url}/debit, etc.          ▲
            │                                                           │
            │ Site pages                    ③ Game screen (new window / iframe)
            │                               navigate to launch_url, WebSocket
 ┌──────────┴───────────────────────────────────────────────────────────┴──┐
 │                              Player browser                             │
 └─────────────────────────────────────────────────────────────────────────┘

Channel	Direction	Purpose	Docs
① Operator API	Operator server → platform	Issue game launch URLs, list games and tables, query round and transaction history, force logout players, manage tables and dealers	Operator API
② Wallet callbacks	Platform → operator server	Balance inquiry (`balance`), withdrawal (`debit`), deposit (`credit`), withdrawal cancellation (`rollback`)	Wallet Callbacks
③ Game screen	Player browser ↔ platform	Lobby and game rendering, real-time play (WebSocket), live video	Game Launch Flow

The source of truth for player balances is the operator wallet (seamless wallet). The platform does not hold player money separately; it calls the wallet callbacks every time money moves.
Game rules, shuffling, outcome determination, and settlement all take place on the platform server. The operator receives the results through wallet callbacks and the history API.
The Operator API and wallet callbacks are server-to-server communication. Never keep API credentials in the browser — store them only on the operator server. The browser requests a game launch through the operator backend.
The only server calls the platform makes to the operator are the four wallet callbacks. There are no separate webhooks or event pushes; history is queried through the Rounds and Transactions API.

Terminology

Term	Description
Operator	A site that contracts with the platform to receive games. Identified by an operator code (e.g. `acme`), which is sent in the `X-Operator` header of every request.
Player `external_id`	The player ID assigned by the operator (a string of 1–64 bytes). The platform identifies a player by the (operator, `external_id`) pair and creates a platform player ID (`pl_…`) on the first launch. This value is passed through unchanged in wallet callbacks as well.
Session	The platform session created when a player enters the game screen. One session is created each time a launch URL is used, and it lasts up to 12 hours.
Table session	In buy-in flow games, the period from taking a seat until standing up (`tss_…`). Buy-in, top-up, and cash-out wallet transactions are grouped by this unit.
Round	A single game (`rnd_…`). In bet flow games, bet and settlement wallet transactions are grouped by round.
`tx_id`	The wallet transaction ID (`tx_…`). The platform generates it deterministically, so a retry of the same transaction arrives with the same `tx_id`. The operator must use this value for duplicate handling (idempotency).
`launch_token`	A one-time token carried in the game launch URL. It can be used only once within 60 seconds, and because it is carried in the URL fragment (`#token=…`) it does not appear in server logs or the Referer header.
Prepaid credit	Credit that the operator tops up with the platform in advance under the `prepaid` operating mode. Each bet (debit) deducts that amount, and wins and cash-outs (credit) return that amount.

ID formats, amount units, and time formats are described in Conventions.

Operating mode (`credit_mode`)

Each operator is assigned one of two operating modes at contract time. The current mode can be checked in the mode field of the GET /credit response.

Item	`prepaid` (prepaid mode)	`independent` (independent mode)
Prepaid credit	Used. Prepaid credit is deducted before the bet debit	Not used
When prepaid credit runs short	Bets and seating are rejected without calling the wallet (player screen error `OPERATOR_CREDIT_EXHAUSTED`)	Not applicable
Debit failure / rollback	The deducted prepaid credit is restored	Not applicable
Credit (wins, cash-outs)	That amount is added to the prepaid credit	Not applicable
Creating dedicated tables	Not available	Available (games permitted by the platform)
Querying dealer card input records	Not available	Available
Private tables	Not available	Available (dedicated Live Hold'em tables)

To be agreed

The operating mode, the prepaid credit top-up and settlement method, and the fee rate are agreed at contract time.

Available games

Games are divided into two kinds (kind) depending on who the player plays against.

Kind (`kind`)	Description	Example games
`table` (P2P)	Games where players compete against each other. Rake (fee) is deducted from the hand result.	Texas Hold'em, Omaha, Live Hold'em, Matgo, Seotda
`round` (banked)	Games played against the house.	Baccarat, Blackjack, Speed Hold'em, Red Dog

The timing of wallet callbacks falls into two patterns, depending on how the game handles chips.

Wallet flow	debit	credit	Games
Buy-in flow	`buy_in` when taking a seat, `top_up` when topping up chips	`cash_out` when standing up (once per table session)	All `table` games, Red Dog
Bet flow	`bet` for each bet (`ante`, `double`, `split` depending on the game)	`settle` once per player at round settlement (amount 0 on a loss)	Baccarat, Blackjack, Speed Hold'em

In buy-in flow games, the wallet is not called for each hand while the player is seated at the table. See Wallet Callbacks for details.

Both live games (dealer video) and RNG games are available. Check which games are enabled for each operator with GET /games. For the full list of game codes, see Game Codes.

Next steps

Integration Process and Environments — information you receive and information you provide, per-environment addresses
Authentication and Signing — bidirectional HMAC signing
Game Launch Flow — sending players to the game screen
Wallet Callbacks — implementing balance, debit, credit, and rollback
Integration Checklist — checks before go-live

Integration Overview ​

Components ​

Terminology ​

Operating mode (credit_mode) ​

Available games ​