Provider API

Rounds and transactions

Read a round with its legs, or every leg in a time window for reconciliation.

GET/provider/v1/rounds/{round_id}200

Answer

{
  "id": 412, "session_id": "…", "player_id": "p-42", "operator_id": "op-7", "currency": "EUR", "demo": false,
  "mode": "BASE", "stake": 100, "debit": 100, "payout": 250, "payout_x100": 250, "book_id": 177,
  "nonce": 3, "client_seed": "…", "server_seed_hash": "…", "status": "settled",
  "created_at": "…", "settled_at": "…",
  "legs": [
    { "transaction_id": "…", "kind": "bet", "amount": 100, "status": "ok", "attempts": 1, "wallet_transaction_id": "…" },
    { "transaction_id": "…", "kind": "win", "amount": 250, "status": "ok", "attempts": 1, "wallet_transaction_id": "…" }
  ]
}

Transactions#

GET/provider/v1/transactions?from=<ISO time>&to=<ISO time>&after=<transaction_id>&limit=<1..1000>200

Every leg we created in the window and at least 30 s ago, oldest first, with next for the following page (after=next). The 30 s margin is longer than any write can take (a lock waits at most 2 s, a statement 5 s), so a page never skips a leg still being written. A leg's status can change after you read it (pending to ok): re-read the window or the round for the final state.

Leg status	Meaning
ok	applied
pending	still being sent
declined	bet refused for funds
failed	bet refused for another reason
unknown	bet that got no answer; always followed by a refund leg
stuck	a win or refund still not applied after 24 hours (we are alerted)

Catalog#

GET/provider/v1/games200

The game catalog: id, RTP per mode, volatility, bet steps, max win, features and a thumbnail_url on our host.

Probes#

GET/health200

GET/ready200

/health checks the process, /ready the database and the loaded outcome tables (the answer is reused for 2 s). 200 or 503.