Torrent Gear

How the API for connecting live games to the platform works

1) Common architecture and component roles

Operator Platform (Casino Platform): accounts, wallet, bonus engine, limits, KYC/AML, transaction log.

Live game provider (Studio/Provider): studios, dealers, video streams (WebRTC/Low-Latency HLS), game server rounds.

Aggregator (sometimes): a single API for dozens of providers, unification of currencies/limits/events.

Client frontend: web/mobile client with betting UI, video player, chat, local prompts.

Auxiliary services: Risk/Anti-fraud, logging, analytics, message queues (Kafka/RabbitMQ), monitoring.

Typical topology: → client (JWT) → → platform (server-to-server) → provider, in parallel, the client receives a video stream from the CDN/media server pool.

2) Player life cycle and sessions

2. 1. Login and "game token"

1. The player logs in to the platform.

2. The platform calls CreateGameSession from the provider (S2S), transmits' player _ id ',' currency ',' country ',' bet _ limits', flags of the responsible game.

3. The provider returns a one-time game_token and launch_url.

4. The client opens' launch _ url'in an iframe/new tab, adding' game _ token '(or gets 302 to the final URL of the game).

Example of an S2S request:

http
POST /api/v1/sessions
Content-Type: application/json
Authorization: Bearer <platform_api_key>

{
"player_id": "u-918273",  "session_id": "sess-5f3b2",  "currency": "EUR",  "country": "DE",  "lang": "de",  "bet_limits": {"min": 0. 5, "max": 2000},  "responsible_gaming": {"self_excluded": false, "deposit_limit_left": 150},  "callback_urls": {
"balance": "https://platform. example. com/wallet/balance",   "debit":  "https://platform. example. com/wallet/debit",   "credit": "https://platform. example. com/wallet/credit",   "rollback":"https://platform. example. com/wallet/rollback",   "events": "https://platform. example. com/game/events"
}
}

Provider response:

json
{
"game_token": "gtkn_7f0...e2a",  "launch_url": "https://live. provider. com/launch/roulette",  "expires_in": 900
}

2. 2. Authentication at the front

The game loads, validates the'game _ token' through its backend.

WebSocket is installed to the game server for bets/events.

The video stream runs over WebRTC (low latency 0. 5-2 s) or LL-HLS (2-5 s).

3) Money and bets: Wallet API and idempotence

3. 1. Balance and debit/credit

The provider does not store the player's "money" - it calls the Platform Wallet API:

`GET /wallet/balance? player_id' → current available.
'POST/wallet/debit '→ write off the bet.
'POST/wallet/credit '→ credit winnings/returns.
'POST/wallet/rollback '→ rolling back a transaction when a round is canceled.

Important: all monetary transactions are'transaction _ id '/' round _ id'. Repeating the same query does not change the result.

Example of debit (rate):

http
POST /wallet/debit
Idempotency-Key: trx-7a2df-001
Content-Type: application/json

{
"player_id": "u-918273",  "round_id": "r-2025-10-18-12:30:15Z-001",  "transaction_id": "trx-7a2df-001",  "amount": 25. 00,  "currency": "EUR",  "bet_type": "roulette_straight",  "meta": {"table_id":"ru-11", "selection":"17", "odds":35}
}

3. 2. Timings and bet statuses

WINDOW_OPEN → WINDOW_CLOSING → WINDOW_CLOSED. After'WINDOW _ CLOSED ', the provider prohibits new debits.

Late bids are rejected with the code'LATE _ BET '.

If the connection is broken, the client can resend the bet - the server must be able to distinguish the duplicate by Idempotency-Key.

Transaction statuses: 'PENDING', 'SETTLED', 'ROLLED _ BACK', 'REJECTED'.

4) Round Events: Model and Order

4. 1. WebSocket Event Schema

`round. started '→ comes' round _ id ', bet timer.

`bet. accepted/rejected '→ confirmation for each bid.

`round. closed '→ bets are no longer accepted.

`round. result '→ outcome (roulette/card/bone sector).

`payout. created '→ amount won by player.

`round. settled '→ final status, checksum.

Example of a result event:

json
{
"type": "round. result",  "round_id": "r-2025-10-18-12:30:15Z-001",  "table_id": "ru-11",  "payload": {
"roulette": {"number":17, "color":"black"},   "hash": "sha256:8a7b...d1c",   "video_ts": "2025-10-18T12:30:23. 450Z"
}
}

4. 2. Consistency and checksums

Each event is supplied with 'seq' and 'signature' (mTLS + signature of the request body).

For reconciliation, 'payout _ checksum' is specified - the sum of all 'round _ id' credits must converge.

5) Video stream and latency

WebRTC for live hand betting (blackjack/baccarat/roulette) - strict delay budget <2 s to customer.

LL-HLS/DASH for viewers/scale, allows 2-5 c.

Time synchronization: NTP/chrony, in payload - 'video _ ts' for replays and disputes.

Folback: when WebRTC degrades, auto-switching to LL-HLS → with blocking late bets.

6) Errors, Retras, Timeouts

General rules:

All S2S calls with a timeout of 800-1500 ms, retrays with exponential pause and Jitter, but without re-debiting money (idempotency).

Wallet error codes:

`INSUFFICIENT_FUNDS`, `LIMIT_EXCEEDED`, `ACCOUNT_LOCKED`, `DUPLICATE_TRANSACTION`, `LATE_BET`, `CURRENCY_MISMATCH`.

Error format:

json
{
"error": "INSUFFICIENT_FUNDS",  "message": "Balance 18. 00 < required 25. 00",  "transaction_id": "trx-7a2df-001"
}

7) Bonuses, freespins, insurance

In parallel with the "money" wallet, there may be a bonus balance: the payload indicates the source of the write-off 'source: CASH	BONUS`.
For live games, insurance/side-bet is not uncommon (for example, in blackjack) - these are separate transactions with their own limits and coefficients.
Rounding rules: banking (half-to-even) or in favor of the player/operator - must be fixed in the integration config.

8) Responsible play and limitations

Session flags: 'self _ excluded', 'cooldown _ until', 'loss _ limit _ left', 'time _ limit _ left'.

The provider can request'validate _ limits' before each debit.

The platform can initiate force_close_session: the player is excluded/exceeded the limit → the provider closes the betting window and makes returns at unplayed bets.

9) Safety and compliance

mTLS for S2S, HSTS, strict IP-allowlist.

JWT/JWS with short TTL for front-end tokens, audience/issuer verification.

Signature of the provider's webhooks (HMAC-SHA256 over the body).

Dealer activity logs, round replays, immutable audit (WORM storage).

Storage of personal data - PII minimization, 'player _ id' tokenization, jurisdiction retention periods (GDPR and analogues).

Geo-blocking and prohibitions by jurisdiction at the CreateGameSession level.

10) Reconciliation and Finance

10. 1. Hourly/daily reports

The provider gives a report on 'round _ id → total_bets, total_wins, fees'. The platform combines:

Debits = Σ bets, Credits = Σ wins + returns, Delta = GGR (including bonuses/jackpots/commissions).

Report format:

json
{
"date": "2025-10-18",  "currency": "EUR",  "tables": [{
"table_id": "ru-11",   "rounds": 1260,   "total_bets": "45230. 00",   "total_payouts": "43012. 50",   "jackpot_contrib": "302. 00",   "provider_fee": "2. 5%"
}]
}

10. 2. Rollback-scenarios

Video/Storyboard → round failed. cancelled: the provider sends a 'rollback' to all bets in the round.

Double debit processing caught on platform → 'DUPLICATE _ TRANSACTION' and 200 OK with the same result.

11) Chat, moderation and UI events

Chat events go through a separate channel (WebSocket # 2) with stopword filters.

System announcements (close bets, winner list) - only from a trusted provider source, signed/timestamped.

12) Testing and certification

Sandbox provider: fixed results, ability to force'round. result`.

QA contour: test table with truncated betting windows (5-8 c) and accelerated flow.

Load: simulation of 5-10 thousand simultaneous players, peak debits per second (TPS) ≥ scheduled × 1. 5.

Integration certification: checklists for idempotency, currencies, rounding, processing outages, compliance with limits and self-exclusion.

13) Metrics and SLO

Those: median/95p latency for 'debit/credit', WebSocket round-trip, time synchronization error, drop-rate WebRTC.

Продукт: bet acceptance rate, late-bet rate, dispute rate, chargeback rate, session duration, retention, ARPU/LTV.

SLO examples:

99. 5% `debit` ≤ 1. 2 s, 99. 9% delivery'round. result '≤ 300 ms after fixation, Video delay ≤ 2. 5 s for 95p WebRTC.

14) Multicurrency, taxes, localization

Conversion - outside the provider: the game works strictly in the session currency.

Taxes/deductions - on the platform side with 'credit' (field 'withholding').

Localization: 'lang', number/currency format, time zone for timers and reports.

15) Integration options

1. Direct-to-Provider: maximum control and feature, but separate contracts/certifications.

2. Through the aggregator: fast coverage by providers, unified schemes, sometimes less flexibility.

3. Hybrid: top tables directly, the rest through an aggregator.

16) Mini-specification (total)

16. 1. WebSocket inbound (client to provider)

json
{ "type":"bet. place", "bet":{
"amount": 25, "selection":"17", "table_id":"ru-11"
}, "idempotency_key":"c3a2-...-001" }

16. 2. WebSocket outbound (provider to client)

json
{ "type":"bet. accepted", "bet_id":"b-8821", "seq":12031 }
{ "type":"round. closed", "round_id":"r-...001", "seq":12050 }
{ "type":"round. result", "result":{"number":17,"color":"black"}, "seq":12070 }
{ "type":"payout. created", "amount":875, "currency":"EUR", "seq":12075 }

16. 3. Wallet S2S (platform ↔ provider)

'POST/wallet/debit '(idempotent)

'POST/wallet/credit '(idempotent)
'POST/wallet/rollback '(idempotent)

HMAC signature, 'Timestamp', 'Nonce', repeat protection (TTL ≤ 60 c).

17) Edge cases and how to close them

Player disconnection: bet sent, no confirmation → repeat with the same'Idempotency-Key '; the server will respond with the same status.

Dealer/deck change in the round: automatic cancellation and full 'rollback'.

Currency mismatch: 'CURRENCY _ MISMATCH' + event log; the game is blocked until the session is re-released.

Self-exclusion at the time of the game: immediate 'force _ close _ session', return unplayed.

Change in video quality: client only, no impact on timers/bets.

WebSocket re-handshake: without loss of order - queue of events with 'seq', "catching up" missed.

18) Production launch checklist

Safety

mTLS + pinning certificate, IP-allowlist.
Sign all webhooks and check'Timestamp '/' Nonce '.
Mini-PII: only 'player _ id' (tokenized).

Reliability

The identity of all monetary transactions.
Round replays and unchangeable auditing.
WebRTC → LL-HLS auto-folback.

Product

Limits/responsible play applied in real time.
Native prompts at time of bet.
Dashboards SLO + alerts 24/7.

The live game integration API is a bundle of low-latency stream, event bus and idempotent wallet with strict requirements for message order, timings and security. Successful implementation relies on: a strict life cycle of bets and rounds, verifiable consistency (reconciliation), data protection and responsible play limits - and turns the "beautiful broadcast" into a reliable, certified financial product.