# Casino Api Pro — full text

> A REST API that supplies provably fair casino games to licensed gaming operators. The operator keeps the players, the wallet, the KYC and the licence; we run the games, the sessions, the round state machine and the settlement ledger.

Generated from the site's own source. Canonical HTML for every section below lives at https://casinoapipro.com.

---

# Documentation

Section: Get started

# Introduction

> What Casino Api Pro is, how the API is structured, and how money is represented.

Source: https://casinoapipro.com/docs/introduction
The Casino Api Pro API lets a licensed operator launch provably fair casino games from one REST integration. You keep the players, the wallet, the KYC and the licence. We run the games, the sessions, the round state machine and the settlement ledger.

## Overview

The API is organised around REST. It uses predictable resource-oriented URLs, accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP verbs and status codes.

There are two directions of traffic, and keeping them straight is most of the integration:

- You call us to list games, open a session and read transactions.
- We call you to move money — every bet and win is a request to your wallet API. See [Wallet integration](/docs/wallet).

## Base URL

All endpoints are served over HTTPS at:

```bash
https://api.casinoapipro.com/v1
```

> **HTTPS only**
>
> Plain HTTP requests are redirected and credentials sent over them should be treated as compromised. There is no HTTP-only fallback.

## How money is represented

Amounts are decimal strings, never JSON numbers. `"10.50"` is valid; `10.5` is rejected with a `VALIDATION_ERROR`. This is deliberate: IEEE-754 doubles cannot represent `0.1` exactly, and a rounding difference between your ledger and ours is the one class of bug that is expensive to unpick after the fact.

```json
{
  "amount": "10.50",
  "currency": "GHS"
}
```

Every amount we return is formatted to the currency's minor units — you will get `"100.00"` and not `"100"`, so string comparison is safe.

## Identifiers

- `transaction_id` — yours. You mint it, and it is the idempotency key for the movement.
- `round_id`, `session_id` — ours. Opaque strings; do not parse them.
- `player_id` — yours. We store it as an opaque string scoped to your operator account.

## Health check

Unauthenticated, and safe to poll from a monitor:

```bash
curl https://api.casinoapipro.com/health
```

```json
{
  "status": "ok",
  "version": "0.1.0",
  "uptime_seconds": 84213
}
```

`GET /health` answers as long as the process is up, which is what you want from a load balancer. `GET /ready` is the stricter one: it actually reaches the database and Redis and reports each with its latency, answering `503` if either is unreachable. Point a load balancer at `/health` and an alert at `/ready` — a node that is up but cannot see its database should stop receiving traffic, not keep accepting bets it cannot record.

```json
{
  "status": "ready",
  "checks": {
    "database": { "ok": true, "latency_ms": 1 },
    "redis":    { "ok": true, "latency_ms": 1 }
  }
}
```

`GET /metrics` is a Prometheus exposition, and its counts come from the ledger rather than from in-process counters — so a restart does not reset them and two API nodes do not report two different truths.

```bash
# HELP capro_operators_active Operators in ACTIVE status.
# TYPE capro_operators_active gauge
capro_operators_active 23
```

> **All three are unauthenticated**
>
> They carry no operator data — counts and latencies only, never a player, a stake or a balance — so there is nothing in them to protect and a monitor does not need a credential to poll them.

## Where to go next

- [Quickstart](/docs/quickstart) — first session in about ten minutes.
- [Authentication](/docs/authentication) — credentials, tokens, scopes.
- [Wallet integration](/docs/wallet) — the five calls we make to you.
- [OpenAPI explorer](https://api.casinoapipro.com/docs) — try every endpoint in the browser.


Section: Get started

# Quickstart

> From nothing to a playable sandbox session in six steps.

Source: https://casinoapipro.com/docs/quickstart
This walks from nothing to a playable game session in the sandbox. Everything here uses play money — no licence is required to complete it, and no real balance can move.

## 1. Get credentials

Ask us for a sandbox account at [casinoapipro.com](/#contact). You will get a dashboard login; create a credential pair there. The secret is shown once — store it in your secret manager before closing the dialog.

_credential (example)_

```json
{
  "api_key": "ck_test_7f3c9a21",
  "api_secret": "cs_test_9d41…shown once"
}
```

## 2. Exchange them for a token

Credentials are long-lived; access tokens are not. Exchange the pair for a bearer token and cache it until it expires.

_cURL_

```bash
curl -X POST https://api.casinoapipro.com/v1/auth/token \\
  -H "Content-Type: application/json" \\
  -d '{
    "api_key": "ck_test_7f3c9a21",
    "api_secret": "cs_test_9d41"
  }'
```

_JavaScript_

```js
const res = await fetch("https://api.casinoapipro.com/v1/auth/token", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ api_key: API_KEY, api_secret: API_SECRET }),
});

const { access_token, expires_in } = await res.json();
```

_PHP_

```php
$ch = curl_init("https://api.casinoapipro.com/v1/auth/token");
curl_setopt_array($ch, [
  CURLOPT_POST => true,
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_HTTPHEADER => ["Content-Type: application/json"],
  CURLOPT_POSTFIELDS => json_encode([
    "api_key" => $apiKey,
    "api_secret" => $apiSecret,
  ]),
]);

$token = json_decode(curl_exec($ch), true)["access_token"];
```

## 3. List the games you can launch

```bash
curl https://api.casinoapipro.com/v1/games \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

The response contains only games enabled for _your_ operator account, with your per-game stake limits already applied.

## 4. Point us at a wallet

Before a session can be created, we need somewhere to send debits and credits. In the sandbox you can skip writing one: create a sandbox player from the dashboard and we will use the built-in play-money wallet, which honours the same idempotency contract as a real one.

> **Test your retries properly**
>
> The sandbox wallet is not a stub that always says yes. It enforces balances, rejects duplicate `transaction_id`s the way production does, and can be told to fail, so your retry path is genuinely exercised before it matters.

## 5. Create a session

_cURL_

```bash
curl -X POST https://api.casinoapipro.com/v1/sessions \\
  -H "Authorization: Bearer $ACCESS_TOKEN" \\
  -H "Content-Type: application/json" \\
  -d '{
    "game_id": "mines",
    "player_id": "your_player_42",
    "currency": "GHS"
  }'
```

_JavaScript_

```js
const session = await api("/v1/sessions", {
  game_id: "mines",
  player_id: "your_player_42",
  currency: "GHS",
});

// Open this in the player's browser. Nothing else is needed.
redirect(session.launch_url);
```

```json
{
  "session_id": "sess_kgv5ws4duteqwhvjobok",
  "launch_url": "https://games.casinoapipro.com/play?token=eyJhbGciOi…",
  "expires_at": "2026-08-29T19:11:56.237Z",
  "game": { "id": "d533d22e…", "slug": "mines", "name": "Mines" },
  "player_id": "your_player_42",
  "currency": "GHS"
}
```

## 6. Open the launch URL

Redirect the player, or drop it into an `<iframe>`. The token in the URL is scoped to one operator, one player and one game, and it is short-lived — mint a fresh session per launch rather than storing the URL.

## What to build next

- [Wallet integration](/docs/wallet) — the five calls that move money.
- [Idempotency](/docs/idempotency) — read before you write retry logic.
- [Webhooks](/docs/webhooks) — round and transaction events, signed.


Section: Get started

# Authentication

> Credential pairs, bearer tokens, the three token audiences, IP allowlisting and rotation.

Source: https://casinoapipro.com/docs/authentication
Every request outside `/v1/public` and the health probes carries a bearer token. Tokens are minted from a credential pair and are scoped to exactly one operator account.

## Credentials

A credential is an `api_key` and an `api_secret`, created in the operator dashboard. We store only a keyed hash of the secret, so we cannot show it to you again and cannot recover it if it is lost — rotate instead.

- Test keys are prefixed `ck_test_` and their secrets `cs_test_`. They can only ever touch play money.
- Live keys are prefixed `ck_live_` and require a paid plan and an approved account.

> **Never ship a secret to a browser**
>
> A credential authenticates your whole operator account. It belongs on your server. The launch URL is the only thing that is safe to hand to a player, and it carries no credential of yours.

## Exchanging for a token

`POST /v1/auth/token` — auth: credential pair

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `api_key` | string | yes | The credential identifier from the dashboard. Begins `ck_test_` or `ck_live_`. |
| `api_secret` | string | yes | The secret shown once at creation. |

```bash
curl -X POST https://api.casinoapipro.com/v1/auth/token \\
  -H "Content-Type: application/json" \\
  -d '{ "api_key": "ck_test_7f3c9a21", "api_secret": "cs_test_9d41" }'
```

```json
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "operator": { "id": "op_2f18c4", "name": "Example Casino", "mode": "TEST" }
}
```

## Using the token

```bash
curl https://api.casinoapipro.com/v1/games \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

Cache the token until shortly before `expires_in` elapses. Minting a fresh token on every request works but counts against your rate limit for no benefit.

## Three audiences, three tokens

A token is issued for one audience and is rejected everywhere else. This is why a launch token cannot be replayed against the operator API.

| Name | Type | Meaning |
| --- | --- | --- |
| `operator-api` | server → us | Server-to-server. Minted from a credential pair. Everything under `/v1/sessions`, `/v1/transactions`, `/v1/games`. |
| `game-launcher` | player browser | Embedded in the launch URL. Scoped to one session, and only valid for `/v1/game/*`. |
| `dashboard` | human | Issued at dashboard login for a human user, not for machine traffic. Everything under `/v1/dashboard`. |

> **Your API credentials cannot reach /v1/dashboard**
>
> The badge on each endpoint in these docs says which audience it accepts, and the split is enforced, not advisory. An `operator-api` token presented to a `/v1/dashboard` route is rejected — including the webhook management endpoints, which is where this most often surprises people. Those are configuration, done by a signed-in human in the dashboard, and there is deliberately no machine credential that can rewrite where your events are delivered. If you need webhook endpoints created as part of a provisioning script, tell us and we will set them up with you rather than issue a key that could be used to redirect your own event stream.

## IP allowlisting

Live accounts may pin credentials to a set of source addresses. Requests from anywhere else are refused with `IP_NOT_ALLOWED` before the secret is even checked. If you need our egress addresses for your own allowlist, ask support — they are static.

## Permissions

A credential can be restricted to what it actually needs. Scopes are `area:read` and `area:write`, across `transactions`, `sessions`, `games`, `history`, `engagement`, and read-only `reports` and `events`.

- Every `GET` needs the area&rsquo;s `read`; every other method needs its `write`.
- A `write` includes its own `read` — you do not have to grant both.
- A credential with no scopes at all is unrestricted. Every key issued before permissions existed is in that state and keeps working.

A request a credential is not scoped for is refused with `INSUFFICIENT_SCOPE`, and the message names the scope it wanted. Set them when you create a key in the dashboard, or change them later without touching the secret.

> **The one worth doing**
>
> Give anything that only reads — a BI job, a reconciliation script, a dashboard of your own — a read-only key. It is the difference between a leaked credential that can copy your figures and one that can empty your float.

## Rotating and revoking

- Rotate issues a new secret for the same API key. The previous secret stops working immediately — there is no overlap window, so deploy the new one in the same change.
- Revoke kills the credential immediately. In-flight tokens minted from it stop working within seconds.
- Delete removes the key and the record of it, including the link from past API request logs. Revoke instead if you may need to answer questions about it later.

> **Rotation has no grace period**
>
> This page used to say the old secret stayed valid for a short overlap. It does not, and never did — the stored hash is replaced in one write. Anything still sending the previous secret starts failing the moment you rotate.

> **If a secret leaks**
>
> Revoke first, ask questions second, then check [the API request log](/docs/request-ids) in the dashboard for calls you do not recognise.


Section: Get started

# Idempotency

> Why every money endpoint is idempotent on your transaction_id, and how to write a retry loop that cannot double-debit.

Source: https://casinoapipro.com/docs/idempotency
Every endpoint that moves money is idempotent on an identifier you supply. Send the same `transaction_id` twice and the money moves once. This is the single most important contract in the API, and the one worth testing hardest.

## How it works

A transaction is claimed by a unique database index on `(operator_id, transaction_id)`. The first request to arrive wins the claim and proceeds to your wallet. Any later request carrying the same id finds the existing record and returns its stored result — it never reaches your wallet a second time.

- The guarantee is enforced by the database, not by application code, so it holds under concurrency.
- It holds across processes and across restarts.
- It is scoped to your operator account — your ids cannot collide with another operator's.

## Choosing an id

Mint it yourself, make it unique, and make it _derivable_ — you must be able to produce the same id again when you retry. A UUID stored alongside the bet in your own database is the usual answer.

```js
// Good: generated once, persisted with the bet, reused on every retry.
const transactionId = bet.id;             // your own primary key
await placeBet({ transaction_id: transactionId, amount: "10.00" });

// Bad: a fresh id per attempt turns one retry into two debits.
await placeBet({ transaction_id: crypto.randomUUID(), amount: "10.00" });
```

## What a replay returns

A replayed request returns the original outcome with `200 OK` — the same balance, the same round, the same everything. It is indistinguishable from the first call except that nothing moved.

```json
{
  "transaction_id": "bet_9f21c4",
  "status": "COMPLETED",
  "balance": "489.50",
  "currency": "GHS",
  "replayed": true
}
```

## Same id, different body

Reusing an id with a different amount, player or currency is a bug on your side, and we treat it as one: the request is rejected with `409 IDEMPOTENCY_CONFLICT` and nothing moves. We will not guess which of the two you meant.

## Timeouts are the whole point

> **A 504 is not a failure**
>
> If a call to your wallet times out, we do not know whether it applied. We leave the transaction `PENDING` and answer `504 WALLET_TIMEOUT`, which is marked retryable. Retry with the same id. The retry resolves the pending record — it does not create a second one.

This is why a fresh id per attempt is dangerous: it converts a recoverable ambiguity into a double debit that only reconciliation will find.

```js
async function settle(bet) {
  for (let attempt = 0; attempt < 5; attempt++) {
    try {
      // Same id every time — that is what makes this safe.
      return await api.post("/v1/transactions/bet", {
        transaction_id: bet.id,
        round_id: bet.roundId,
        player_id: bet.playerId,
        amount: bet.amount,
        currency: bet.currency,
      });
    } catch (err) {
      if (!err.retryable) throw err;
      await sleep(2 ** attempt * 250);
    }
  }
  throw new Error("wallet did not settle; leave for reconciliation");
}
```

## What is not idempotent

Reads are naturally safe to repeat. Session creation is not idempotent — calling it twice mints two sessions, which is harmless but wasteful. See [Sessions](/docs/sessions).


Section: Get started

# Rate limits

> Per-plan throughput, the headers that report it, why a 503 is not a 429, and how to back off.

Source: https://casinoapipro.com/docs/rate-limits
Limits exist so one integration cannot degrade another. They are generous for normal play and tight enough to contain a runaway retry loop.

## Response headers

Every authenticated response carries your current standing:

```http
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 574
X-RateLimit-Reset: 1756487400
Retry-After: 12
```

| Name | Type | Meaning |
| --- | --- | --- |
| `X-RateLimit-Limit` | integer | Requests permitted in the current window. |
| `X-RateLimit-Remaining` | integer | Requests left in it. |
| `X-RateLimit-Reset` | unix seconds | When the window rolls over. |
| `Retry-After` | seconds | Present only on a 429. Wait at least this long. |

## What is limited

Limits are per operator account, not per credential — minting more credentials does not buy more throughput. Money endpoints are limited separately from reads, so a burst of reporting queries cannot starve settlement.

- Money — bet, win, refund, rollback.
- Sessions — creating and closing sessions.
- Reads — catalogue, transactions, reporting.
- Public — the unauthenticated catalogue and contact endpoints, limited by IP.

## Your plan's throughput

The figure below is the floor your account is guaranteed across the authenticated endpoints. Individual routes may allow more — a plan raises a limit, it never lowers one.

| Name | Type | Meaning |
| --- | --- | --- |
| `Sandbox` | 300/min | Enough to build and test against. |
| `Starter` | 600/min | A first live casino. |
| `Growth` | 1,800/min | Several brands at once. |
| `Business` | 6,000/min | Volume. |
| `Enterprise` | agreed | Written into the contract. |

If you are hitting these in normal play that is a conversation rather than a hard ceiling — ask, and we will look at the traffic with you.

## 503 is different from 429, and you must handle it

A `429` means _you_ asked for too much. A `503` means _we_ could not serve you: under saturation the platform sheds load rather than falling over, and it sheds from the bottom — unauthenticated traffic first, then Sandbox and Starter, and only past its own capacity anything above that.

```json
{
  "error": {
    "code": "SERVICE_UNAVAILABLE",
    "message": "the platform is shedding load — retry shortly",
    "request_id": "7c2e1f90-…",
    "retryable": true
  }
}
```

> **Treat 503 as retryable, not fatal**
>
> A client that treats it as a permanent failure will drop bets during a busy minute that would have succeeded a second later. Honour `Retry-After` and use the same backoff you use for a 429.

Settlement is never shed. Wins, refunds, rollbacks and crash cash-outs are excluded at every pressure level, whatever your plan. Refusing a bet is survivable; refusing the win that follows one would leave a player short and a ledger half-written. Health and status are never shed either.

## When you are limited

```json
{
  "error": {
    "code": "RATE_LIMITED",
    "message": "too many requests; retry after 12s",
    "request_id": "7c2e1f90-…",
    "retryable": true
  }
}
```

> **Back off exponentially, and add jitter**
>
> A fleet that retries on a fixed interval will re-converge into the same spike that caused the limit. Exponential backoff with randomness spreads the retry out.

```js
function backoff(attempt, retryAfterSeconds) {
  // Honour the server's own number when it gives one.
  if (retryAfterSeconds) return retryAfterSeconds * 1000;
  const base = Math.min(2 ** attempt * 250, 30_000);
  return base * (0.5 + Math.random()); // jitter: 50–150% of base
}
```

## Edge protection

Traffic also passes a WAF and an edge rate limiter before it reaches the API. A request blocked there gets a Cloudflare error page rather than our JSON envelope — if you see HTML where you expected JSON, that is what happened, and it usually means an unusual request pattern rather than an outage.


Section: Get started

# Errors

> The error envelope, status codes, the retryable flag, and how to handle failures well.

Source: https://casinoapipro.com/docs/errors
Every error, from any endpoint, has the same shape. Parse the `code` — the `message` is written for a human reading a log and may change without notice.

## The envelope

```json
{
  "error": {
    "code": "INSUFFICIENT_FUNDS",
    "message": "player balance is below the requested stake",
    "request_id": "fa1bc6b7-bd54-480e-92c1-6ffa700d6039",
    "retryable": false
  }
}
```

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `code` | string | yes | Stable machine-readable identifier. Branch on this. |
| `message` | string | yes | Human-readable detail. Not stable; do not parse. |
| `request_id` | string | yes | Quote this to support and we can find the exact request. Also returned as the `X-Request-Id` header on every response. |
| `retryable` | boolean | yes | Whether retrying the identical request with the same `transaction_id` can succeed. |

> **retryable is the field that matters**
>
> It removes the guesswork from your retry loop. If it is `true`, back off and send the same request again. If it is `false`, retrying will fail the same way forever — fix the request or surface it.

## Status codes

| Name | Type | Meaning |
| --- | --- | --- |
| `400` | Bad Request | Malformed body — not JSON, or a field of the wrong shape. |
| `401` | Unauthorized | Missing, expired or invalid token. |
| `403` | Forbidden | Authenticated, but not permitted — wrong audience, suspended account, or an IP outside the allowlist. |
| `404` | Not Found | No such resource, or it belongs to another operator. We do not distinguish the two. |
| `409` | Conflict | Idempotency conflict — same `transaction_id`, different body. |
| `422` | Unprocessable | Well-formed but invalid: a stake outside limits, an unsupported currency, an illegal move. |
| `429` | Rate limited | Too many requests. Honour `Retry-After`. |
| `500` | Server error | Our fault. Retryable. Quote the request id if it persists. |
| `504` | Wallet timeout | Your wallet did not answer in time. Retryable with the same id — see [Idempotency](/docs/idempotency). |

## Why 404 and not 403

Asking for another operator's session returns `404`, not `403`. Answering "forbidden" would confirm the resource exists, which leaks the shape of other tenants' data to anyone willing to enumerate ids. Absence and denial look identical from outside.

## Handling errors well

```js
const res = await fetch(url, options);
const body = await res.json();

if (!res.ok) {
  const { code, retryable, request_id } = body.error;

  // Log the request id with everything. It is the only thing that lets
  // support find your exact call in our logs.
  logger.warn({ code, request_id, status: res.status }, "casinoapipro error");

  if (retryable) return scheduleRetry();

  switch (code) {
    case "INSUFFICIENT_FUNDS": return tellPlayer("Not enough balance");
    case "BET_LIMIT_EXCEEDED": return tellPlayer("Stake above the table limit");
    case "IDEMPOTENCY_CONFLICT": return alertEngineering(request_id);
    default: return alertEngineering(request_id);
  }
}
```

A full list of codes lives in [Error codes](/docs/error-codes).


Section: Get started

# Request IDs & logs

> The X-Request-Id header, passing your own trace id through, and what to log.

Source: https://casinoapipro.com/docs/request-ids
Every response carries an `X-Request-Id`. It is the fastest route from "something went wrong" to an answer, and the first thing support will ask for.

It travels in both directions. The id on a call you make to us is one half; the id we put on a call we make to _your_ wallet is the other, and that is the half most integrations need, because most movements are raised by a player inside the launcher rather than by you.

## The header

```http
HTTP/1.1 422 Unprocessable Entity
X-Request-Id: fa1bc6b7-bd54-480e-92c1-6ffa700d6039
Content-Type: application/json
```

The same value appears as `request_id` inside every error body, so you can log it whether or not you keep response headers.

## Supplying your own

Send `X-Request-Id` and we will use it instead of generating one. If you already have a trace id, passing it through means one identifier spans your logs and ours.

It must be 1–128 characters of letters, digits, dot, colon, underscore or hyphen — the shapes real tracing produces, UUIDs and hex trace ids included. Anything else is dropped and we generate our own instead.

> **Dropped rather than cleaned up**
>
> A header is latin-1 on the wire, so an id carrying anything outside that set came back altered — `abcédef` was returned as `abcédef`, which no longer matches what you sent and fails to correlate without saying so. A visibly generated id tells you nothing usable arrived; half of yours would not.

> **On calls you make, not on rounds your players play**
>
> We adopt your id on calls authenticated with your API credential. A request from inside the launcher is made by the player's browser on a launch token, so we always generate our own there — a value a player chose must not end up in your wallet log looking like ours.

```js
await fetch(url, {
  method: "POST",
  headers: {
    "Authorization": \
```

## What to log

- The request id, on both success and failure.
- The error `code`, never the message.
- Your `transaction_id`, so a support question can be answered from either end.
- Never the token, never the credential secret.

```js
logger.warn({
  request_id: body.error.request_id,
  code: body.error.code,
  transaction_id: payload.transaction_id,
  status: res.status,
}, "casinoapipro rejected a movement");
```

## The id on calls we make to you

Every call we make to your wallet carries `x-request-id`. It is our id for the request that caused the movement: the same id we returned to you when you raised it through `/v1/transactions/*`, and our id for the player's action when the launcher raised it — in which case you never saw it, because you made no call.

> **Missing on launcher rounds until 13 September 2026**
>
> The header went out on movements an operator raised directly and not on movements the launcher raised, which is almost all of them. An operator who followed this page and stored it ended up with a column that was always null. It is sent on every call now.

Store it against your own wallet row. It is the one value that exists on both sides of the conversation, and you can quote it straight back at us:

`GET /v1/rounds/{roundId}/wallet-calls` — auth: operator-api

That returns every movement we raised on a round with your wallet's response body verbatim and the `request_id` we sent on each. See [running it from your own servers](/docs/automation).

> **One id can cover more than one movement**
>
> A single player action often raises two — a bet and a win settle together — and both carry the same id, because the action is the thing you would be asked about, not the leg.

## The API request log

`GET /v1/api-logs` — auth: operator-api

A searchable log of your recent calls — method, path, status, request id and duration — in the dashboard and over the API. It is the right first stop when an integration behaves differently in production than on your machine, because it shows what we actually received rather than what you believe you sent.

> **It covers calls you make to us, and only those**
>
> A round played inside the launcher makes no call of yours, so it appears here not at all. For those, the record is `GET /v1/rounds/{roundId}/wallet-calls` above.


Section: Get started

# Test mode & live mode

> What differs between sandbox and production, and the checklist for going live.

Source: https://casinoapipro.com/docs/test-and-live
Every account starts in test mode. Test and live are separate credentials, separate data and separate money — there is no flag that turns one into the other by accident.

## What differs

| Name | Type | Meaning |
| --- | --- | --- |
| `Credentials` | ck_test_ / ck_live_ | Prefixed so you can tell at a glance which environment a log line came from. |
| `Money` | play / real | Test credentials cannot move real money under any circumstances. |
| `Wallet` | separate records | Each environment has its own wallet integration. Test mode can use the built-in play-money wallet or your staging one; live uses whatever you configured for live, and never falls back. |
| `Games` | same | Identical engine, identical mathematics, identical versions. Only the money differs. |
| `Data` | separate | Players, sessions, rounds, transactions, free bets and your API request log all belong to one environment. A test player is not a live player even under the same player_id, and nothing you see in one mode is ever from the other. |
| `Rate limit` | same | Your planu2019s requests-per-minute budget, identical in both. Test traffic is not given a looser allowance, so a load test in sandbox measures the limit you will actually meet. |

> **Nothing crosses between them**
>
> The separation is enforced per request, not per screen. A sandbox credential cannot read a live round, a live one cannot read a sandbox round, and the dashboard filters every list — including the API request log — on the mode you are in. There is no endpoint that returns both and no parameter that widens one to the other: a credential carries its environment in its token and cannot ask for the other.

> **The engine is the same code**
>
> Sandbox is not a simulator. Rounds are computed by the same versioned engine, with the same provable-fairness commitments, and settled through the same idempotent state machine. A result you get in test is the result you would have got live.

## One host, two kinds of key

There is no separate sandbox hostname. Every request in both environments goes to `https://api.casinoapipro.com`, and the key you exchange for a token is what puts you in one environment or the other. Nothing else in your integration changes between them — not the host, not a header, not a query parameter.

```http
https://api.casinoapipro.com    ck_test_…  →  sandbox
https://api.casinoapipro.com    ck_live_…  →  live
```

The token you get back carries the environment, and every route reads it from there. A live token cannot see sandbox data and a test token cannot move real money; there is no flag that turns one into the other.

> **The health endpoint says nothing about your account**
>
> `GET /health` returns `status`, `version` and `uptime_seconds` — it is unauthenticated and tells you the platform is up, not what you are entitled to. Read your own state from the dashboard or [the account endpoints](/docs/account) instead.

## Going live

Issuing live credentials is self-service: you generate them in the dashboard the moment your plan is active. There is no approval queue and nothing to wait for on our side. What is worth doing first is proving the parts that are expensive to get wrong in production.

- Configure a live wallet integration. It is a separate record from your sandbox one. Until it exists, live money calls fail with `WALLET_NOT_CONFIGURED` — deliberately, rather than falling back to the play-money wallet. This is the single commonest thing missed on the first live bet.
- Prove your wallet is idempotent — replay the same `transactionId` and confirm one movement.
- Prove your retry path — make the sandbox wallet time out and confirm you recover without double-debiting.
- Prove your reversal path — refund a bet and confirm you match on `referenceTransactionId`, not on the reversal's own id. See [the wallet contract](/docs/wallet).
- Verify webhook signatures against the raw body, and confirm you deduplicate on event id.
- Swap the credentials.

> **Keep the test credentials working**
>
> The commonest post-launch incident is a change shipped straight to live because the sandbox integration was retired. Keep it, and point your staging environment at it.


Section: Integrate

# Game catalogue

> Listing the games enabled for your account, and what each field means.

Source: https://casinoapipro.com/docs/catalogue
The catalogue is what your account can launch — not everything we host. Enabling a game is a toggle in your dashboard; there is no new endpoint and no release on your side.

## List games

`GET /v1/games` — auth: operator-api

**Query**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `limit` | integer | no | Page size, 1–200. Defaults to `50`. |
| `cursor` | string | no | The `next_cursor` from the previous page. |
| `category` | string | no | Filter by category, e.g. `INSTANT` or `CRASH`. Case-insensitive. |
| `provider` | string | no | Filter by provider name. Case-insensitive, exact match. |
| `q` | string | no | Substring match on name or slug. |
| `enabled_only` | true | false | no | Defaults to `true`: only games enabled for you, and active on the platform. Pass `false` to see the rest of your catalogue with `enabled: false`. |

```bash
curl https://api.casinoapipro.com/v1/games \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

```json
{
  "data": [
    {
      "id": "0f7c2a1e-5b3d-4c8a-9e11-6d2f8b40c7aa",
      "slug": "mines",
      "name": "Mines",
      "provider": "Casino Api Pro",
      "category": "INSTANT",
      "thumbnail_url": "https://assets.casinoapipro.com/games/mines.80b81d64.svg",
      "rtp": "97.000",
      "volatility": "variable",
      "min_bet": "0.10",
      "max_bet": "50000.00",
      "max_win": "500000.00",
      "currencies": ["GHS"],
      "enabled": true,
      "status": "ACTIVE",
      "is_multiplayer": false
    }
  ],
  "next_cursor": null,
  "has_more": false
}
```

> **There is no count field**
>
> The response is a cursor page, not a total. Paginate by following `next_cursor` while `has_more` is true; both are always present, and `next_cursor` is `null` on the last page. With seven games in the catalogue one request is the whole of it, but do not build on that.

## Fields worth knowing

| Name | Type | Meaning |
| --- | --- | --- |
| `id` | uuid | Our identifier. This is what arrives as `gameId` in [wallet calls](/docs/wallet), so store it if you key on it there. |
| `slug` | string | Stable human-readable identifier. Use it as `game_id` when creating a session — that endpoint accepts either. |
| `rtp` | decimal string | Theoretical return as a percentage, three decimals, _without_ a percent sign — `"97.000"` means 97%. Derived from the release’s mathematics, never typed by hand. Null only if unset. |
| `min_bet / max_bet / max_win` | decimal string | Your account limits, already applied — not the platform-wide ones. These are the numbers your bets are actually validated against. |
| `enabled` | boolean | Whether _you_ may launch it. Always true unless you asked for `enabled_only=false`. |
| `status` | string | The game’s platform-wide state, e.g. `ACTIVE`. A game can be enabled for you and still be down for maintenance. |
| `volatility` | string | Free text, not an enum, and lower case: today the values are `low`, `medium`, `high`, `variable` and `player-chosen`. Display it; do not switch on it. |
| `is_multiplayer` | boolean | True when one round settles many players at once, as in `goal-jet`. Shared among _your_ players: each operator flies their own. Affects how rounds appear in reporting. |
| `thumbnail_url` | string | Content-hashed and safe to cache forever. The URL changes when the art does. Your own uploaded artwork wins over ours here. |

## Currencies

Every game accepts every currency your account holds. There is no per-game currency list to be added to, and nothing to ask us for: add a currency under Settings → Business, or `PATCH /v1/business`, and every game accepts it on the next session.

The `currencies` field above is therefore your account&rsquo;s list, not a property of the game — it answers &ldquo;what can I open a session in&rdquo;, which is what anyone reading it is asking. Codes are ISO 4217 and validated when you set them, so a typo is refused at that point rather than surfacing later as sessions failing in a currency that does not exist. `GET /v1/public/currencies` lists every code we accept, with its minor units.

> **Stake limits follow the currency**
>
> A release carries one set of limits. They are restated in the session&rsquo;s currency and rounded, so a minimum of `0.50` is about 140 rupees or 12,500 dong rather than half a paisa — roughly the same economic bet in every currency. Set your own per-currency limits and yours are used instead; they may narrow the platform&rsquo;s figures, never widen them.

## Fetch one game

`GET /v1/games/{gameId}` — auth: operator-api

Accepts either the slug or the id, and returns exactly the object above — the same fields, no more. For the mathematics of a specific release, see [provably fair](/docs/provably-fair).

```bash
curl https://api.casinoapipro.com/v1/games/mines \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

A slug that exists on the platform but is not in your catalogue returns `404 GAME_NOT_FOUND`, the same as one that does not exist at all.

## The public catalogue

There is also an unauthenticated version, used by our own marketing site. It shows games that are live on the platform, without account-specific limits, and is rate limited by IP.

```bash
curl https://api.casinoapipro.com/v1/public/games
```

```json
{
  "count": 5,
  "categories": ["CRASH", "INSTANT"],
  "data": [
    {
      "slug": "goal-jet",
      "name": "Goal Jet",
      "provider": "Casino Api Pro",
      "category": "CRASH",
      "description": "A shared flight every player watches at once…",
      "thumbnail_url": "https://assets.casinoapipro.com/games/goal-jet.613da995.svg",
      "rtp": "97.00%",
      "volatility": "high",
      "min_bet": "0.50",
      "max_bet": "50000.00",
      "currencies": ["GHS", "NGN", "KES", "USD", "EUR"],
      "is_multiplayer": true,
      "tags": ["crash", "multiplayer", "popular"],
      "version": "1.1.0"
    }
  ]
}
```

> **It is a different shape, and not the one to integrate against**
>
> The public response is a whole list with a `count`, not a cursor page. Its `rtp` carries a percent sign (`"97.00%"`) where the authenticated one does not (`"97.000"`). It adds `description`, `tags` and `version`, and omits `id`, `max_win`, `enabled` and `status`. Its limits are the platform defaults, not yours. Build against `/v1/games`.


Section: Integrate

# Sessions & launch

> Creating a session, opening the launch URL, session lifecycle, and closing early.

Source: https://casinoapipro.com/docs/sessions
A session binds one player to one game for one sitting, and produces the launch URL you open in their browser. It is the only object you need to create in order to start play.

## Create a session

`POST /v1/sessions` — auth: operator-api

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `game_id` | string | yes | The game's slug (`"mines"`) or id. Slugs are stable and easier to read in logs. |
| `player_id` | string | yes | Your identifier for the player. Opaque to us, scoped to your account. |
| `currency` | string | yes | ISO 4217, e.g. `"GHS"`. Must be enabled for both your account and the game. |
| `ttl_seconds` | integer | no | Shorten the session lifetime. Cannot exceed your account default. |
| `brand_id` | string | no | Which of your brands this sitting belongs to, if you run more than one. |
| `player_name` | string | no | Display name shown in multiplayer games, 1–40 characters. Never used for identity, and never matched against anything. Sent on any session it replaces the stored name; omitted, the stored one is kept. |
| `return_url` | string | no | Where the launcher sends the player when they close the game. |

> **A name you send is shown as you sent it**
>
> A player who arrives without `player_name` appears as their `player_id` with all but the first and last character masked — safe, and unreadable. A name you supply is shown verbatim instead, because you chose it for this purpose: we do not mask it again, so `"***417"` stays `"***417"` rather than becoming `"***7"`. Send a username or a handle you are happy for other players to see — never a phone number or anything a player signs in with.

_cURL_

```bash
curl -X POST https://api.casinoapipro.com/v1/sessions \\
  -H "Authorization: Bearer $ACCESS_TOKEN" \\
  -H "Content-Type: application/json" \\
  -d '{
    "game_id": "mines",
    "player_id": "your_player_42",
    "currency": "GHS",
    "return_url": "https://your-casino.com/lobby"
  }'
```

_JavaScript_

```js
const session = await api.post("/v1/sessions", {
  game_id: "mines",
  player_id: player.id,
  currency: player.currency,
  return_url: "https://your-casino.com/lobby",
});

res.redirect(session.launch_url);
```

_PHP_

```php
$session = $client->post("/v1/sessions", [
  "game_id"    => "mines",
  "player_id"  => $player->id,
  "currency"   => $player->currency,
  "return_url" => "https://your-casino.com/lobby",
]);

header("Location: " . $session["launch_url"]);
```

```json
{
  "session_id": "sess_kgv5ws4duteqwhvjobok",
  "launch_url": "https://games.casinoapipro.com/play?token=eyJhbGciOi…",
  "expires_at": "2026-08-29T19:11:56.237Z",
  "game": { "id": "d533d22e…", "slug": "mines", "name": "Mines" },
  "player_id": "your_player_42",
  "currency": "GHS"
}
```

## Opening the launch URL

Redirect to it, or embed it in an `<iframe>` with `allow="autoplay; fullscreen"`. The token inside is scoped to one operator, one player and one game, and it is short-lived.

> **Do not cache the launch URL**
>
> Mint a fresh session each time the player opens the game. A stored URL will expire, and a shared one is a URL that plays on someone else's balance.

## Lifecycle

- `ACTIVE` — created, and playable until it expires.
- `CLOSED` — ended by you, or by the player leaving.
- `EXPIRED` — passed `expires_at`. Any open round is settled or voided first.

Sessions are not idempotent — calling create twice mints two sessions. That is harmless, but prefer one per launch so your reporting matches the player's experience.

## Fetch a session

`GET /v1/sessions/{sessionId}` — auth: operator-api

```bash
curl https://api.casinoapipro.com/v1/sessions/sess_kgv5ws4duteqwhvjobok \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

## Close a session early

`POST /v1/sessions/{sessionId}/close` — auth: operator-api

Use this when a player self-excludes mid-sitting, or when you need to stop play immediately. An open round is settled if it can be and voided if it cannot — a void refunds the stake through your wallet.

```bash
curl -X POST https://api.casinoapipro.com/v1/sessions/sess_kgv5ws4d/close \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

## Next

- [Wallet integration](/docs/wallet) — what happens once the player bets.
- [Provably fair](/docs/provably-fair) — what the launcher commits to.


Section: Integrate

# Wallet integration

> The five calls we make to your wallet, every field on the wire, and the contract it must honour.

Source: https://casinoapipro.com/docs/wallet
We never hold a player balance. Every movement is a request from us to your wallet API, and your wallet is the authority on whether it happened. Deposits, withdrawals, KYC and the player relationship stay entirely with you.

## Which way the calls go

```http
Player  →  Your platform      accounts · KYC · wallet
                 ↕              wallet API   (we call you)
           Casino Api Pro       sessions · ledger · webhooks
                 ↕              outcome
             Game engine        provably fair results
```

You configure one base URL and we call five paths beneath it. Paths, field names, auth and error codes are all configurable per operator, so a wallet that already speaks its own dialect usually needs no changes at all. Everything on this page is the default — what we send if you configure nothing but the base URL.

> **Casing differs by direction, and it is deliberate**
>
> Requests _you_ send _us_ are snake_case (`reference_transaction_id`). Requests _we_ send _your wallet_ are camelCase (`referenceTransactionId`) by default, because that is what most wallets we integrate already use. If you would rather receive snake_case, set a field map — see [renaming fields](/docs/wallet#fieldmap). Nothing about this is guessable, so it is spelled out below field by field.

## Configuring it

Everything on this page is set in your dashboard under Developer → Wallet: the base URL, the five paths, the authentication method and its credential, the field names, timeouts and retries. Sandbox and live are separate records — configuring one does not configure the other, and neither falls back to the other.

The page shows the five URLs your settings actually resolve to, and a Test connection button that performs a real balance read against your wallet and reports what came back. A balance read moves nothing, so it is safe against a live wallet, and it exercises the whole chain — URL resolution, transport, authentication, signature and response shape. Use it before your first bet rather than after.

## The five operations

| Name | Type | Meaning |
| --- | --- | --- |
| `balance` | a read | Current balance for a player. Carries only `playerId` and `currency`. Safe to retry. |
| `debit` | a bet | Money leaves the player. Must fail if the balance is insufficient. |
| `credit` | a win | Money returns to the player. |
| `refund` | a round that could not finish | Returns a specific earlier debit, named by `referenceTransactionId`. |
| `rollback` | a correction | Voids an earlier movement in full, named by `referenceTransactionId`. Always the full value — there is no partial rollback. |

## The default paths

```http
POST  {base_url}/wallet/balance
POST  {base_url}/wallet/debit
POST  {base_url}/wallet/credit
POST  {base_url}/wallet/refund
POST  {base_url}/wallet/rollback
```

All five are POST, including `balance`. Override any of them individually in your wallet integration settings; the ones you do not override keep the defaults above.

> **A path prefix on your base URL is dropped unless you ask for it**
>
> Paths are resolved against your base URL as URLs, not concatenated as strings. A base URL of `https://wallet.example.com/api/v2` with the default absolute paths resolves to `https://wallet.example.com/wallet/debit` — the `/api/v2` is gone. To keep a prefix, end the base URL with a slash (`https://wallet.example.com/api/v2/`) and configure _relative_ paths (`debit`, not `/debit`). That resolves to `https://wallet.example.com/api/v2/debit`.

## What we send

A bet. Only the four required fields appear here because this movement has nothing else to carry:

_POST {base_url}/wallet/debit_

```json
{
  "transactionId": "bet_9f21c4",
  "playerId": "your_player_42",
  "amount": "10.00",
  "currency": "GHS"
}
```

A refund, with everything populated. `referenceTransactionId` is the id of the original debit; `transactionId` is the id of this reversal:

_POST {base_url}/wallet/refund_

```json
{
  "transactionId": "rfd_4a90b1",
  "playerId": "your_player_42",
  "amount": "10.00",
  "currency": "GHS",
  "roundId": "rnd_7c31ea",
  "gameId": "0f7c2a1e-5b3d-4c8a-9e11-6d2f8b40c7aa",
  "sessionId": "sess_kgv5ws4d",
  "referenceTransactionId": "bet_9f21c4",
  "gameName": "Mines",
  "reason": "round could not be settled",
  "metadata": { "platform_transaction": "0b41…" }
}
```

**Every field we can send**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `transactionId` | string | yes | The id of _this_ movement, and the key your idempotency must be built on. It is the `transaction_id` you gave us when you called our API. |
| `playerId` | string | yes | Your own player identifier, exactly as you sent it when the session was created. |
| `amount` | decimal string | yes | Always a string, always positive, always in minor-unit-free decimal form — `"10.00"`, never `10` or `1000`. |
| `currency` | string | yes | ISO 4217 code of the session. |
| `roundId` | string | no | Present on every movement belonging to a round. Absent on balance reads. |
| `gameId` | uuid | no | Our uuid for the game — not the slug. The slug is in `gameName`’s sibling catalogue; if you key on the slug, map it once at integration time. |
| `sessionId` | string | no | The launch session the movement belongs to. |
| `referenceTransactionId` | string | no | The original transaction on refund and rollback. Present only on those two operations, and only when the reversal names a target — which, through our API, it always does. |
| `gameName` | string | no | Human-readable name, for your statements and support tooling. |
| `reason` | string | no | Free text you supplied on the reversal, passed through unchanged. |
| `metadata` | object | no | Whatever you attached, plus `platform_transaction` — our internal id for the movement, which is what our support will ask you for. |

> **Two things that are not in the body**
>
> There is no `timestamp` field and no nested `game` object. The time of the request is a header, and only when HMAC signing is on — see [securing the callback](/docs/wallet#security). Game identity is the two flat fields `gameId` and `gameName`.

### Absent, not null

Optional fields we do not have are omitted from the JSON entirely — we never send `null` for them. A schema that requires `roundId` to be present will reject our balance reads.

### Renaming fields

Seven keys can be renamed: `transactionId`, `playerId`, `amount`, `currency`, `roundId`, `gameId`, `sessionId` and `referenceTransactionId`. Set a field map on your wallet integration and we send your names instead:

_wallet integration → field map_

```json
{
  "transactionId": "transaction_id",
  "playerId": "player_id",
  "roundId": "round_id",
  "gameId": "game_id",
  "sessionId": "session_id",
  "referenceTransactionId": "reference_transaction_id"
}
```

`gameName`, `reason` and `metadata` are not remappable and always arrive under those exact names.

## What we expect back

A `200` with the resulting balance. That is the whole success contract.

```json
{
  "balance": "489.50",
  "currency": "GHS"
}
```

**Fields we read from your response**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `balance` | decimal string | no | The balance after the movement. A number is accepted, but a string avoids float artefacts entirely. |
| `reference` | string | no | Your own id for the movement. Stored and shown in our transaction records, which makes reconciliation with your ledger a lookup rather than an investigation. |
| `duplicate` | boolean | no | Set it `true` when you recognised the `transactionId` and did not move money again. Optional, and useful: it lets us distinguish a replay from a fresh movement in reporting. |

All three are remappable through `responseMap` if your wallet nests them elsewhere — dotted paths like `data.balance` work.

## Refusing a movement

Answer with a non-2xx and a code we can map. Any of these shapes is read correctly:

```json
{ "error_code": "INSUFFICIENT_FUNDS" }
{ "code": "INSUFFICIENT_FUNDS" }
{ "error": "INSUFFICIENT_FUNDS" }
{ "error": { "code": "INSUFFICIENT_FUNDS", "message": "balance 4.20" } }
```

Matching ignores case, hyphens and spaces, so `insufficient-funds` and `INSUFFICIENT_FUNDS` are the same string to us. These are the codes we recognise without being told, and what your player and your API call see as a result:

| Name | Type | Meaning |
| --- | --- | --- |
| `insufficient_funds` | → 402 | Aliases: `insufficient_balance`, `not_enough_funds`, `low_balance`. The bet is refused and the round never opens. |
| `player_blocked` | → 403 | Alias: `player_disabled`. Self-exclusion, KYC hold, or any other reason you will not accept play. |
| `player_not_found` | → 403 | Alias: `unknown_player`. Unknown player id — usually a session opened for someone since deleted. |
| `currency_mismatch` | → 422 | Alias: `invalid_currency`. The player does not hold the session currency. |
| `transaction_not_found` | → 404 | Alias: `reference_not_found`. On a refund or rollback: the `referenceTransactionId` means nothing to you. |
| `already_reversed` | → 409 | Aliases: `already_refunded`, `already_rolled_back`. You have already reversed it. Usually it is us retrying, and this is the right answer. |
| `invalid_request` | → 502 | Alias: `unauthorized`. We sent something you cannot accept, or could not authenticate. This is a bug on one side and is escalated. |

Anything else is a terminal rejection — the movement fails, your API call gets a `502` with `WALLET_REJECTED`, and we do not retry. Your string is preserved verbatim in the transaction record either way, so an unmapped code is diagnosable rather than lost. If you have codes of your own, map them to ours in your wallet integration instead of leaving them to fall through.

## The three rules your wallet must honour

- Be idempotent on `transactionId`. If you have seen the id, return the same balance you returned the first time and do not move money again. We retry, and we retry with the same id on purpose.
- Be atomic. Apply the movement and record the id in one transaction. Doing them separately opens a window where a crash loses one or the other.
- Answer quickly. The default timeout is six seconds, with two retries and exponential backoff. Beyond it we treat the call as indeterminate, leave the transaction pending and retry.

> **The dangerous case is a timeout, not a rejection**
>
> A clean rejection is easy — nothing moved. A timeout is ambiguous: your wallet may have applied the debit and failed to answer. That is exactly why we retry with the same id, and exactly why your wallet must recognise it.

## A correct handler

```js
app.post("/wallet/debit", async (req, res) => {
  const { transactionId, playerId, amount, currency } = req.body;

  const result = await db.transaction(async (tx) => {
    // The unique index on transaction_id is what makes this safe. Checking
    // first and inserting later races under concurrency; let the DB decide.
    const existing = await tx.movements.findByTransactionId(transactionId);
    if (existing) return { balance: existing.balance_after, replayed: true };

    const player = await tx.players.lockById(playerId);
    if (lessThan(player.balance, amount)) {
      throw new WalletError("insufficient_funds", 402);
    }

    const balance = subtract(player.balance, amount);
    await tx.players.setBalance(playerId, balance);
    await tx.movements.insert({ transactionId, playerId, amount, balance_after: balance });
    return { balance };
  });

  res.json({ balance: result.balance, currency, duplicate: result.replayed === true });
});
```

Refund and rollback differ only in what they look up first:

```js
app.post("/wallet/refund", async (req, res) => {
  const { transactionId, referenceTransactionId, playerId, amount, currency } = req.body;

  const result = await db.transaction(async (tx) => {
    // Idempotency is still on OUR id for this reversal…
    const existing = await tx.movements.findByTransactionId(transactionId);
    if (existing) return { balance: existing.balance_after, replayed: true };

    // …and referenceTransactionId is what it reverses. Unknown means say so:
    // answering 200 here credits a player against a bet that never took money.
    const original = await tx.movements.findByTransactionId(referenceTransactionId);
    if (!original) throw new WalletError("transaction_not_found", 404);
    if (original.reversed_at) throw new WalletError("already_reversed", 409);

    const balance = add((await tx.players.lockById(playerId)).balance, amount);
    await tx.players.setBalance(playerId, balance);
    await tx.movements.markReversed(original.transactionId);
    await tx.movements.insert({ transactionId, playerId, amount, balance_after: balance });
    return { balance };
  });

  res.json({ balance: result.balance, currency, duplicate: result.replayed === true });
});
```

## Securing the callback

Five authentication modes are available on a wallet integration: `NONE`, `BEARER`, `BASIC`, `API_KEY_HEADER` and `HMAC_SIGNATURE`. Signing is not on unless you turn it on, and for a live wallet you should.

Under `HMAC_SIGNATURE` we add two headers. The timestamp is Unix seconds — not milliseconds, not ISO 8601 — and it is signed alongside the body so a captured request cannot be replayed under a fresh one:

```http
x-timestamp: 1788321861
x-signature: 4d1b8f0a5c2e9a7b3f6d8c1e0a4b7d2f9c3e6a1b8d5f0c7e2a9b4d6f1c8e3a0b

signature = hex( HMAC_SHA256( secret, "{x-timestamp}" + "." + "{raw request body}" ) )
```

| Name | Type | Meaning |
| --- | --- | --- |
| `Encoding` | lowercase hex | Not base64, and no scheme prefix — the header value is the 64 hex characters and nothing else. |
| `Signed string` | {timestamp}.{body} | A literal dot between them. The body is the exact bytes we sent — verify before parsing, because re-serialising changes them. |
| `Header names` | x-signature / x-timestamp | Both configurable per integration if your wallet expects different ones. |
| `Freshness` | your call | We do not require a window. Rejecting timestamps older than five minutes is the usual choice, and is yours to make. |

_verifying, in Node_

```js
import { createHmac, timingSafeEqual } from "node:crypto";

// rawBody must be the unparsed bytes. express.json() discards them unless you
// ask: express.json({ verify: (req, _res, buf) => { req.rawBody = buf; } })
function verify(secret, req) {
  const ts = req.get("x-timestamp");
  const sig = req.get("x-signature");
  if (!ts || !sig) return false;
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;

  const expected = createHmac("sha256", secret)
    .update(\
```

> **Wallet signatures and webhook signatures are not interchangeable**
>
> The algorithm and the signed string are identical, but the headers are not. Webhooks arrive as `x-capro-signature: v1=<hex>` with `x-capro-timestamp` — note the `v1=` prefix, which wallet signatures do not have. Strip it before comparing. See [webhooks](/docs/webhooks).

## Headers we always send

```http
content-type: application/json
accept: application/json
user-agent: CasinoApiPro/1.0 (+https://casinoapipro.com)
x-request-id: 01J8Z4Q7F2K9M3N5P7R9T1V3W5
```

`x-request-id` is our id for the request that caused the movement. When you raised it yourself through `/v1/transactions/*` it is the same id we returned to you. When it came from a player acting inside the launcher — which is most rounds — it is our id for that play, which you never saw: you did not make a call.

> **It was missing on launcher rounds until 13 September 2026**
>
> The header was sent on movements an operator raised directly and not on movements the launcher raised, which is almost all of them — so an operator who followed this page and stored the value ended up with a column that was always null. One of them told us. It is sent on every call now.

Log it. It is the one value that appears on both sides of the conversation: `GET /v1/rounds/{roundId}/wallet-calls` returns it as `request_id` against each movement, so a value in your log can be quoted straight back at ours. Add static headers of your own on the integration if your gateway needs them.

## Testing without writing one

There is no separate sandbox hostname. Every environment is `https://api.casinoapipro.com`, and your API key decides which one you are in — `ck_test_` keys are sandbox, `ck_live_` keys are live. See [test and live](/docs/test-and-live).

In sandbox you can use the built-in reference wallet with play money instead of building anything. It enforces balances and idempotency exactly as production does, and it can be told to add latency or fail a proportion of calls, so you can prove your retry path works before you build the real thing.

> **Sandbox and live wallets are configured separately**
>
> A wallet integration belongs to one environment. Configuring the sandbox does not configure live — until a live integration exists, live money calls fail with `WALLET_NOT_CONFIGURED` rather than falling back to anything. That is deliberate: a sandbox wallet settling real bets is the worst failure this platform could have, and both the code and a database constraint refuse it.


Section: Integrate

# Transactions

> Bet, win, refund and rollback; transaction states; and why the ledger is append-only.

Source: https://casinoapipro.com/docs/transactions
Four endpoints move money, and one reads it back. All four are idempotent on your `transaction_id` — read [Idempotency](/docs/idempotency) before writing retry logic.

## Debit a bet

`POST /v1/transactions/bet` — auth: operator-api

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `transaction_id` | string | yes | Yours. The idempotency key for this movement. |
| `player_id` | string | yes | The player being debited. |
| `game_id` | string | yes | The game's slug, e.g. `"mines"`. |
| `round_id` | string | yes | Yours, not ours. You mint the round id and reuse it for every movement in that round — the bet, the win, and any refund. It is how we group them. |
| `amount` | decimal string | yes | The stake, e.g. `"10.00"`. Never a JSON number. |
| `currency` | string | yes | ISO 4217. Must match the session. |
| `session_id` | string | no | The session this bet belongs to. Optional, but supply it — it is what ties the movement to a sitting in reporting. |
| `metadata` | object | no | Flat key/value pairs echoed back on reads. Strings, numbers and booleans only. |

```bash
curl -X POST https://api.casinoapipro.com/v1/transactions/bet \\
  -H "Authorization: Bearer $ACCESS_TOKEN" \\
  -H "Content-Type: application/json" \\
  -d '{
    "transaction_id": "bet_9f21c4",
    "player_id": "your_player_42",
    "game_id": "mines",
    "round_id": "round_7c31ea",
    "amount": "10.00",
    "currency": "GHS",
    "session_id": "sess_kgv5ws4d"
  }'
```

```json
{
  "transaction_id": "bet_9f21c4",
  "round_id": "round_7c31ea",
  "status": "COMPLETED",
  "type": "BET",
  "amount": "10.00",
  "currency": "GHS",
  "balance": "489.50",
  "created_at": "2026-08-29T15:04:21.118Z"
}
```

## Credit a win

`POST /v1/transactions/win` — auth: operator-api

The same body shape as a bet. Reuse the `round_id` you sent with the bet — that is what pairs them. A win of zero is legal and closes the round as a loss.

```json
{
  "transaction_id": "win_9f21c4",
  "player_id": "your_player_42",
  "game_id": "mines",
  "round_id": "round_7c31ea",
  "amount": "24.00",
  "currency": "GHS"
}
```

## Refund

`POST /v1/transactions/refund` — auth: operator-api

Returns a specific earlier bet in full, naming it with `reference_transaction_id`. Use it when a round cannot be completed — a game fault, a session closed mid-round, a provider outage.

```json
{
  "transaction_id": "refund_9f21c4",
  "reference_transaction_id": "bet_9f21c4",
  "player_id": "your_player_42",
  "game_id": "mines",
  "round_id": "round_7c31ea",
  "amount": "10.00",
  "currency": "GHS",
  "reason": "round could not be completed"
}
```

## Rollback

`POST /v1/transactions/rollback` — auth: operator-api

Voids an earlier movement in full, naming it with `reference_transaction_id`. Where a refund says "give the stake back", a rollback says "this never happened" — it is the correction of record when a round is annulled.

> **A rollback takes no amount**
>
> It is always for the full value of what it reverses. Letting a caller name an amount invites a partial rollback that neither side can reconcile afterwards.

```json
{
  "transaction_id": "rollback_9f21c4",
  "reference_transaction_id": "bet_9f21c4",
  "player_id": "your_player_42",
  "reason": "round annulled"
}
```

> **Refund or rollback?**
>
> Refund the stake when the _player_ should be made whole for a round that could not finish. Roll back when the _movement itself_ was wrong and the books must not show it. If in doubt, refund: it is the one that leaves a clearer audit trail.

## Retrieve a transaction

`GET /v1/transactions/{transactionId}` — auth: operator-api

Looks up by your id, which means you can always resolve the ambiguity after a timeout: ask us what happened to it.

```bash
curl https://api.casinoapipro.com/v1/transactions/bet_9f21c4 \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

## Transaction states

| Name | Type | Meaning |
| --- | --- | --- |
| `PENDING` | in flight | Claimed, but your wallet has not confirmed. A retry with the same id resolves it. |
| `COMPLETED` | terminal | Your wallet confirmed. The ledger entry is written and immutable. |
| `FAILED` | terminal | Your wallet refused. No money moved. |
| `ROLLED_BACK` | terminal | Reversed by a later rollback. The original entry remains — the reversal is a new one. |

## The ledger is append-only

- Entries are never updated or deleted; a correction is a new entry pointing at the old one.
- Enforced by a database trigger, not by convention, so a bug in our code cannot rewrite history.
- A report run twice returns the same answer, even after a correction.


Section: Integrate

# Webhooks

> Events, payload shape, signature verification, the retry schedule, and the history you can pull.

Source: https://casinoapipro.com/docs/webhooks
Webhooks tell your systems what happened without polling. Every delivery is signed, retried with exponential backoff, and idempotent on a stable event id.

## Events

These seven names are the complete list. Subscribing to a name outside it is rejected when you create the endpoint, so a typo fails immediately rather than silently delivering nothing. Leave the event list empty to receive all of them.

| Name | Type | Meaning |
| --- | --- | --- |
| `game.session.created` | event | A launch session was opened for a player. |
| `round.started` | event | A round opened. |
| `round.completed` | event | A round reached a terminal state. Carries the payout and the outcome. |
| `transaction.bet` | event | A stake settled against your wallet. Refunds also arrive under this name — read `data.type` to tell them apart. |
| `transaction.win` | event | A win settled against your wallet. |
| `transaction.failed` | event | A movement was refused and will not be retried. |
| `transaction.rollback` | event | A movement was voided. |

## Payload

Every delivery has the same six-field envelope. Only `data` varies by type.

_round.completed_

```json
{
  "id": "evt_3f81a2c9",
  "type": "round.completed",
  "created_at": "2026-08-29T15:07:44.902Z",
  "environment": "LIVE",
  "operator_id": "fad629aa-4b17-408f-9fbd-dbad4f8ac1a7",
  "data": {
    "round_id": "rnd_7c31ea",
    "game": "mines",
    "wallet_round_id": "34f97fee-7e98-43c8-9e6f-4652b6ef9840",
    "wallet_game_id": "a662fecf-b8b4-42d3-af7f-de0ca998b89d",
    "player_id": "your_player_42",
    "stake": "10.00",
    "payout": "24.00",
    "currency": "GHS",
    "free_bet": false,
    "outcome": { "…": "game-specific" },
    "fairness": {
      "server_seed_hash": "9c1185a5c5e9fc54612808977ee8f548…",
      "client_seed": "player-chosen",
      "nonce": 41
    }
  }
}
```

`outcome` is the same reveal the player saw, so it can be shown to them without translation — the tiles opened and where the bombs were for `mines`, the roll and the target for `dice`, the angle and the pick for `spin-bottle`. `fairness` carries the triple needed to verify the round, so the event alone is enough; see [provably fair](/docs/provably-fair). A null `client_seed` means the player never set one and is treated as the empty string in the seed string — the round still verifies.

> **Joining an event to the wallet calls it caused**
>
> The event speaks in public handles — `round_id` is `rnd_…` and `game` is a slug — while wallet calls carry uuids. So `wallet_round_id` and `wallet_game_id` are also here: they are exactly the `roundId` and `gameId` we sent on the debit and credit for this round. Join on those rather than pairing by timestamp and amount, which cannot distinguish two identical stakes seconds apart.

> **free_bet is the field to branch on**
>
> A free bet raises no debit — the player is not paying — and a losing one pays nothing. So a losing free-bet round settles without a single call to your wallet, and this event is the only record that it happened. Two things follow for your ledger: a winning free bet is a credit with no matching debit, which is correct rather than a fault; and `stake` is here because on those rounds there is no debit of yours to read it from.

_transaction.bet_

```json
{
  "id": "evt_5c02de71",
  "type": "transaction.bet",
  "created_at": "2026-08-29T15:07:44.118Z",
  "environment": "LIVE",
  "operator_id": "fad629aa-4b17-408f-9fbd-dbad4f8ac1a7",
  "data": {
    "transaction_id": "bet_9f21c4",
    "reference": "txn_0b41f7",
    "type": "BET",
    "status": "SUCCESS",
    "amount": "10.00",
    "currency": "GHS",
    "player_id": "your_player_42",
    "round_id": "rnd_7c31ea"
  }
}
```

**The envelope**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `id` | string | yes | Stable across redeliveries of the same event. This is what you deduplicate on. |
| `type` | string | yes | One of the seven names above. |
| `created_at` | ISO 8601 | yes | When the event happened, not when this attempt was sent. Redeliveries keep the original value; the attempt number is in the `x-capro-delivery-attempt` header. |
| `environment` | SANDBOX | LIVE | yes | Which environment produced it. Worth asserting on if one endpoint receives both. |
| `operator_id` | uuid | yes | Your account id. |
| `data` | object | yes | Type-specific. Treat unrecognised fields as additive — we add them without a version bump. |

> **data.type is not envelope type**
>
> On transaction events the envelope `type` is the event name (`transaction.bet`) and `data.type` is the movement kind (`BET`, `WIN`, `REFUND`, `ROLLBACK`). A refund arrives as `transaction.bet` with `data.type: "REFUND"`, so branch on `data.type` when the distinction matters to your ledger.

## Verifying the signature

Every delivery carries these headers:

```http
x-capro-event-id: evt_3f81a2c9
x-capro-event-type: round.completed
x-capro-timestamp: 1788321861
x-capro-signature: v1=4d1b8f0a5c2e9a7b3f6d8c1e0a4b7d2f9c3e6a1b8d5f0c7e2a9b4d6f1c8e3a0b
x-capro-delivery-attempt: 1

signature = "v1=" + hex( HMAC_SHA256( secret, "{x-capro-timestamp}" + "." + "{raw body}" ) )
```

| Name | Type | Meaning |
| --- | --- | --- |
| `Header names` | x-capro-* | All five are prefixed. There is no bare `X-Signature` on a webhook. |
| `The v1= prefix` | must be stripped | The header value is `v1=` followed by the hex. Comparing the whole value against a bare digest never matches. The prefix is a version marker so a future scheme can be added without breaking you. |
| `Encoding` | lowercase hex | 64 characters. Not base64. |
| `Timestamp` | Unix seconds | A string of ten digits. Not milliseconds, not ISO 8601. |
| `Signed string` | {timestamp}.{body} | A literal dot between them, over the exact bytes we sent. |

> **Verify against the raw body**
>
> Parse the JSON only after the signature checks out. Re-serialising the body first will change a byte somewhere and the comparison will fail for reasons that take a day to find.

_Express_

```js
import crypto from "node:crypto";

// Raw body, not the parsed object.
app.post("/webhooks/casinoapipro", express.raw({ type: "*/*" }), (req, res) => {
  const header = req.get("x-capro-signature") ?? "";
  const timestamp = req.get("x-capro-timestamp");
  if (!header || !timestamp) return res.sendStatus(400);

  // Reject anything old enough to be a replay of a captured request.
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) {
    return res.sendStatus(400);
  }

  const expected = crypto
    .createHmac("sha256", process.env.WEBHOOK_SECRET)
    .update(\
```

_PHP_

```php
$raw       = file_get_contents("php://input");
$header    = $_SERVER["HTTP_X_CAPRO_SIGNATURE"] ?? "";
$timestamp = $_SERVER["HTTP_X_CAPRO_TIMESTAMP"] ?? "";

// Strip the "v1=" version prefix before comparing.
[$version, $signature] = array_pad(explode("=", $header, 2), 2, "");

if ($version !== "v1" || $signature === "" || $timestamp === "") {
  http_response_code(400);
  exit;
}

if (abs(time() - (int) $timestamp) > 300) {
  http_response_code(400);
  exit;
}

$expected = hash_hmac("sha256", $timestamp . "." . $raw, getenv("WEBHOOK_SECRET"));

if (! hash_equals($expected, $signature)) {
  http_response_code(401);
  exit;
}

http_response_code(200);
$event = json_decode($raw, true);
```

> **Wallet calls are signed differently**
>
> If you also verify our calls to your wallet, note the headers there are `x-signature` and `x-timestamp` with no `v1=` prefix and no `capro` in the name. Same algorithm, same signed string, different headers — see [securing the callback](/docs/wallet#security).

## Rotating the signing secret

Rotating issues a new secret and keeps the previous one valid for a window you choose — 24 hours by default. While that window is open, every delivery carries both signatures in one `x-capro-signature` header, space separated:

```http
x-capro-signature: v1=4d1b8f0a…  v1=9e2c7b40…
```

Accept the delivery if either matches. That is what lets you deploy the new secret whenever it suits you instead of racing the rotation: without the overlap, every event between the rotation and your deploy fails verification.

> **Write the loop before you need it**
>
> A receiver that compares the header to a single value works perfectly until the first rotation and then rejects everything. Split on spaces from day one — it costs one line and it is the difference between rotating on a Tuesday afternoon and never rotating.

## Testing an endpoint

The dashboard can send a `webhook.test` delivery to any endpoint and show you exactly what came back — status, timing, and the body on failure. It travels the same path as a real event and is signed the same way, so a pass means a real event will arrive.

A failed test does not count against the endpoint&rsquo;s failure streak. A test is a question, and a question answered &ldquo;no&rdquo; should not pause the endpoint you are in the middle of setting up.

## Retries

Any response outside `2xx`, and any timeout, is retried with exponential backoff over roughly 24 hours. After the final attempt the delivery is marked failed and appears in the dashboard, where you can replay it once your endpoint is healthy.

- Answer `200` as soon as you have durably stored the event; do the work afterwards.
- Deduplicate on `id` — at-least-once delivery means you will occasionally see one twice.
- Order is not guaranteed. Use `created_at` if sequence matters.

## Reading events you were not delivered

`GET /v1/events` — auth: operator-api

Every event is recorded whether or not an endpoint is subscribed to it, and this is where you read them from. That means a webhook added today can be backfilled over the period before it existed, and that an outage on your side longer than the retry window is recoverable rather than lost.

**Query**

| Name | Type | Meaning |
| --- | --- | --- |
| `type` | string | One of the seven names above. Omit for all of them. |
| `from / to` | ISO 8601 | Inclusive, UTC. Defaults to the last 7 days. |
| `limit` | integer | Page size, 1–200. Defaults to `50`. |
| `cursor` | string | The `next_cursor` from the previous page. |

```bash
curl "https://api.casinoapipro.com/v1/events?type=round.completed&from=2026-08-01" \
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

Events come back oldest first — a backfill is replayed forward, and paging a newest-first list while new events arrive skips rows. Each one is the same envelope a delivery carries, so one handler serves both. There is no environment parameter: a credential belongs to one environment and the history you get is its own.

> **Reading is not delivery**
>
> Fetching an event here does not mark it delivered, and it does not affect retries. Polling this endpoint and receiving webhooks are two ways to read the same history — use either, or both while you cut over.

`GET /v1/events/{eventId}` — auth: operator-api

Fetch one by the `id` from its envelope — useful when a delivery arrived but your handler failed to store it.

## Managing endpoints

`POST /v1/dashboard/webhooks` — auth: dashboard

`GET /v1/dashboard/webhook-deliveries` — auth: dashboard

`POST /v1/dashboard/webhook-deliveries/{id}/retry` — auth: dashboard

The signing secret is shown once at creation, exactly like an API credential.

> **These take a dashboard session, not your API credentials**
>
> Note the `dashboard` badge above. These routes accept a token issued at dashboard login for a human user; an `operator-api` token minted from your `ck_live_` credentials is rejected on them. In practice you manage webhook endpoints in the dashboard UI, and nothing in your server integration needs to call these. See [token audiences](/docs/authentication#audiences).


Section: Reference

# Provably fair

> Seed commitment, the hash-to-float derivation, rotation and verification, and versioned mathematics.

Source: https://casinoapipro.com/docs/provably-fair
Every outcome is derived from a hash the player can recompute. We commit to a server seed before play by publishing its hash, and reveal the seed when it is rotated — so a player can check, after the fact, that we did not choose the outcome once we knew their bet.

## The scheme

- Server seed — secret, ours, revealed on rotation.
- Client seed — the player's, changeable at any time.
- Nonce — a counter, incremented once per round.

```js
const hash = sha256(\
```

That single float drives the round. What it selects — which tile is a mine, where the multiplier stops — is the game's own mathematics, versioned per release.

## The commitment

Before a round, the launcher can read the current commitment: the _hash_ of the server seed, never the seed.

`GET /v1/game/state` — auth: game-launcher

```json
{
  "fairness": {
    "server_seed_hash": "9c1185a5c5e9fc54612808977ee8f548b2258d31…",
    "client_seed": "player-chosen-or-generated",
    "nonce": 41
  }
}
```

## Rotating and verifying

`POST /v1/game/seed/rotate` — auth: game-launcher

Rotation reveals the old server seed and commits to a new one in the same response. With the revealed seed the player can recompute every round played under it.

```json
{
  "revealed": {
    "server_seed": "8f14e45fceea167a5a36dedd4bea2543…",
    "server_seed_hash": "9c1185a5c5e9fc54612808977ee8f548…",
    "rounds": 41
  },
  "next": { "server_seed_hash": "b6589fc6ab0dc82cf12099d1c2d40ab9…" }
}
```

> **What the player checks**
>
> That `sha256(revealed.server_seed)` equals the hash committed _before_ they played. If it matches, the seed could not have been chosen after seeing their bets.

## Setting a client seed

`POST /v1/game/seed/client` — auth: game-launcher

A player who supplies their own client seed removes any doubt about our influence over the input. Setting one rotates the nonce back to zero.

## Versioned mathematics

Every game release is versioned, and each round records the version it was played under. A change to a payout table is a new release, never an edit — so a round played last year can still be verified against the exact mathematics in force at the time.

| Name | Type | Meaning |
| --- | --- | --- |
| `game_version` | string | Recorded on the round. What a regulator asks for first. |
| `server_seed_hash` | string | The commitment in force when the round was played. |
| `nonce` | integer | This round’s position in the seed’s sequence. |

## Where the randomness comes from

Server seeds are drawn from the operating system's CSPRNG. Nothing in the engine calls a seeded or time-based generator, and the engine has no access to a player's balance or stake when it computes an outcome — the mathematics and the money are separate layers by design.


Section: Reference

# Game actions

> The launcher-side endpoints for every game: Mines, Magic Ball, Spin da’ Bottle, Under Over 7, Dice, Lucky Wheel, Nova Drop and Goal Jet.

Source: https://casinoapipro.com/docs/game-actions
These endpoints are called by the game launcher in the player's browser, with the short-lived token from the launch URL — not by your server. They are documented because you will see the resulting rounds and transactions, and because some operators build their own front end.

> **You usually do not call these**
>
> Open the launch URL and our launcher handles all of it. Read on only if you are building a custom client against `/v1/game/*`.

## Session state

`GET /v1/game/state` — auth: game-launcher

Everything a client needs to render: the session, the player's balance as your wallet last reported it, the stake limits, and the current fairness commitment.

## The generic action endpoint

`POST /v1/game/play/{action}` — auth: game-launcher

Every single-player game is driven through one endpoint. Adding a game does not add an endpoint — the action name and body are defined by the game's own contract, which is why our catalogue can grow without your client changing.

## Mines

### Start a round

`POST /v1/game/play/start` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stake` | decimal string | yes | The stake. Debited before the grid is generated. |
| `mines` | integer | yes | How many mines on the 5×5 grid. More mines, higher multipliers. |

```json
{
  "round_id": "rnd_7c31ea",
  "state": "ACTIVE",
  "revealed": [],
  "multiplier": "1.00",
  "balance": "489.50"
}
```

### Pick a tile

`POST /v1/game/play/pick` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `tile` | integer | yes | 1–25. Picking a tile that is already open is refused. |

A safe tile raises the multiplier. A mine ends the round at zero and reveals the whole grid, so the player can verify the layout against the seed.

### Cash out

`POST /v1/game/play/cashout` — auth: game-launcher

Settles at the current multiplier and credits the win through your wallet. Cashing out with nothing revealed is refused.

## Magic Ball

`POST /v1/game/play/play` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stakes` | decimal string[3] | yes | One stake per cup, in order. `"0"` means no chip on that cup — the player is not picking one cup, they are placing chips, and may cover more than one. |
| `client_seed` | string | no | Optional. Folded into the fairness commitment for this round. |

At least one cup must carry a chip, and no more than `maxSpots` of them (two by default) — covering all three would be a stake that cannot lose, which is not a game.

## Spin da’ Bottle

`POST /v1/game/play/spin` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stake` | decimal string | yes | The stake. |
| `pick` | string | yes | `"up"` or `"down"`. Settled on the spin. |
| `client_seed` | string | no | Optional. Folded into the fairness commitment for this round. |

## Under Over 7

`POST /v1/game/play/roll` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stake` | decimal string | yes | The stake. |
| `pick` | string | yes | `"under"` (2–6), `"seven"` (exactly 7) or `"over"` (8–12). |

Two dice, settled immediately. The response carries both `dice`, their `total`, the `outcome` that total fell into, and the `multiplier` the chosen call pays.

> **Every call returns the same, so the seven is not a worse bet**
>
> Two dice give 15 ways in 36 for either range and 6 for the seven, and each multiplier is derived from its own odds and the configured return — 2.32× and 5.82× at 97%. The cabinets this game comes from pay a flat 2×/3×/2×, which returns 83.3% on a range and 50% on the seven: the bet that looks exciting is the worst on the table. Show your players the chance beside the multiplier and neither is a trap.

```json
{
  "round_id": "rnd_8q2v…",
  "dice": [3, 4],
  "total": 7,
  "outcome": "seven",
  "pick": "seven",
  "multiplier": "5.82",
  "status": "won",
  "stake": "1.00",
  "payout": "5.82"
}
```

## Dice

`POST /v1/game/play/roll` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stake` | decimal string | yes | The stake. |
| `target` | integer | yes | Win under this. Bounded by the release&rsquo;s `minTarget` and `maxTarget`, 2–98 by default. |

A number in 0.00–99.99 is drawn and you win if it comes in strictly under your target, settled immediately. The response carries the `roll`, the `target`, the `multiplier` that target pays and its `win_chance`.

> **Every target returns the same, so a long shot is not a worse bet**
>
> The multiplier is the configured return divided by the target&rsquo;s own odds, floored to two places — 97 ÷ 50 = 1.94× at a target of 50, and 97 ÷ 2 = 48.5× at a target of 2. A player picking a long shot is choosing variance, not a worse price, and showing the win chance beside the multiplier is what makes that visible.

```json
{
  "round_id": "rnd_3k9m…",
  "roll": "42.17",
  "target": 50,
  "multiplier": "1.94",
  "win_chance": "50%",
  "status": "won",
  "stake": "1.00",
  "payout": "1.94"
}
```

## Lucky Wheel

`POST /v1/game/play/spin` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stake` | decimal string | yes | The stake. Every prize is a multiple of it. |

Sixteen faces, one draw, settled immediately. The response carries the `segment` that came up, its `multiplier`, and the `angle` the rim stopped at — the last only so a client can animate to the answer the server already gave.

> **The faces are equal and the chances are not**
>
> Sixteen equal chances at this ladder would return 2352%, so the wheel is weighted. The weights are part of the certified release, come back on `GET /v1/game/state` as `config.segments`, and are what a player re-derives when verifying a round. A client drawing its own ladder would eventually draw one the engine had stopped using — read them from the session.

```json
{
  "round_id": "rnd_ipskzzin6dxe2f5vmr6k",
  "segment": 7,
  "multiplier": "0.6",
  "angle": "168.7500",
  "status": "won",
  "stake": "2.00",
  "payout": "1.20",
  "server_seed_hash": "2040c88d…",
  "nonce": "1"
}
```

## Nova Drop

`POST /v1/game/play/drop` — auth: game-launcher

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `stake` | decimal string | yes | The stake. Every prize is a multiple of it. |
| `rows` | integer | no | Rows of pegs, `8`–`16`. Defaults to `8`. |
| `risk` | string | no | `"low"`, `"medium"` or `"high"`. Defaults to `"medium"`. |
| `balls` | integer | no | Balls in this drop, `1`–`10`. The stake is charged per ball. Defaults to `1`. |

A ball falls through a triangle of pegs into the slots below it, settled immediately. The response carries the `slot` it landed in, that slot&rsquo;s `multiplier`, the `rows` and `risk` the round was played at, and — unlike every other game here — the whole `path`.

> **The seed reproduces the route, not just the result**
>
> Every other game draws one number and maps it to an outcome. This one draws one per row, so the revealed seed reproduces which side of every peg the ball took, in order. `path` is a string of `L` and `R`, one character per row, and the slot is simply the number of `R`s — a player can verify the bounce as well as the payout, and a board that dropped a ball down a path its seed does not generate would be caught by anyone who looked.

> **Risk changes the payouts and never the odds**
>
> The chance of reaching a slot is Pascal&rsquo;s row for the row count — eight rows give 1:8:28:56:70:56:28:8:1 out of 256 — and it is identical on all three risk settings. Risk moves only what each slot pays, and the return is the same on every setting, so higher risk is more variance and not a worse bet. Say so in your UI: the number that sells the game is the corner multiplier, and the number that makes it a decision is the chance beside it.

> **A flight is one round, and the stake is per ball**
>
> `balls: 10` is ten bets in one round: the round is charged ten times the stake, and it returns what all ten balls made. Do not make ten calls — a player may hold one open round per game, so concurrent drops are refused with `ROUND_IN_PROGRESS`. One round also means one wallet debit and one credit rather than ten of each. Show the TOTAL in your UI. Ten balls at a stake is ten times the risk of one, and a panel displaying only the per-ball figure is telling a player they are risking a tenth of what they are. Each ball still draws from its own indices — ball `b`, row `i` uses `b × rows + i` — so every ball in a flight stays independently verifiable, and `balls[]` carries each one&rsquo;s path, slot, multiplier and payout. The first ball is repeated at the top level so an integration written before flights existed keeps working unchanged.

> **Offer only the boards your release certifies**
>
> A release carries every board a player may choose, keyed `rows:risk`, and comes back on `GET /v1/game/state` as `config.boards`. A request for a combination the release does not carry is refused rather than settled against a ladder nobody signed off. Read the keys from the session rather than assuming the full 8–16 range.

```json
{
  "round_id": "rnd_e5jfco5u72zkwkosvpmn",
  "path": "RRRRLRLR",
  "slot": 6,
  "rows": 8,
  "risk": "medium",
  "multiplier": "1.01",
  "balls": [
    { "path": "RRRRLRLR", "slot": 6, "multiplier": "1.01", "payout": "1.01" },
    { "path": "LRRLRRRL", "slot": 5, "multiplier": "0.503", "payout": "0.50" },
    { "path": "RRLRRRRR", "slot": 7, "multiplier": "3.52", "payout": "3.52" }
  ],
  "status": "won",
  "stake": "3.00",
  "payout": "5.03",
  "server_seed_hash": "863b48d8…",
  "nonce": "1"
}
```

## Goal Jet — a shared round

Crash games work differently: one flight is shared by everyone playing at your casino, so the round is not owned by a single player. Stakes go on before it starts; each player cashes out on their own.

> **Your flight is yours**
>
> Each operator flies their own. Your players share a flight with each other and with nobody else, its crash points are computed from the RTP _you_ set, and its round numbers count within your casino. A flight starts when your first player arrives rather than running against an empty table.

`GET /v1/game/crash/state` — auth: game-launcher

`POST /v1/game/crash/bet` — auth: game-launcher

`POST /v1/game/crash/cashout` — auth: game-launcher

- A player may hold more than one stake on the same flight.
- Cash-out moves through `ACTIVE → SETTLING → WON`. If your wallet times out mid-settlement, the retry resumes at the _same_ multiplier — a player can never be shown a win we then fail to pay.
- The flight's crash point is committed before betting opens and verifiable afterwards, exactly as in [Provably fair](/docs/provably-fair).

### A flight sleeps when nobody is playing

It stops after about two minutes without a player and wakes on the next sign of life — which now includes `POST /v1/sessions`, so by the time your player's launcher connects the round is already open. Flying empty tables for every operator every quarter second is waste, and this is how it is avoided.

While it is asleep the last round stays in the table exactly as it ended, so `/crash/state` tells you which you are looking at:

| Name | Type | Meaning |
| --- | --- | --- |
| `flight_status: "running"` | field | The round below is the live one. |
| `flight_status: "starting"` | field | Nothing was flying. Reading the state has woken it — poll again and there will be a round. Do not offer a stake against the round in this response: it has already settled and the bet will be refused with `ROUND_ALREADY_SETTLED`. |
| `flight_idle_seconds` | field | How long it had been asleep. Null when running. |

> **This was missing until 14 September 2026**
>
> Neither field existed, so a client could not tell a round that crashed five seconds ago from one that crashed eight days ago. An operator's players were shown the latter and their stakes refused against it, and nothing in the catalogue, the session response or the launch URL said the flight was not running. They found it by reading their own logs.

To check without starting anything — and without minting a session you may not use — use `GET /v1/catalogue/{gameId}/flight` on the operator API. Reading it does not wake the flight. See [running it from your own servers](/docs/automation).

## Round history

`GET /v1/game/history` — auth: game-launcher

This player's recent rounds in this game, with the fairness record attached to each so the client can offer a verify button without another round trip.


Section: Integrate

# Rounds & history

> Your rounds, movements, sessions, players and free bets — listed, for your servers.

Source: https://casinoapipro.com/docs/history
Your own rounds, players, sessions, movements and free bets, listed — the same records the dashboard shows, for your servers rather than a person in a browser. Everything here is read with your API credentials and scoped to the calling key's environment.

> **Anything you can read here, you can automate**
>
> These exist because the split was never a decision. The dashboard grew these screens first, and a server had no way to ask the same questions — `GET /v1/rounds` answered 404 to operators building reconcilers against their own data. If something is still missing, tell us; the gap is an accident, not a policy.

## Paging and windows

Every list here takes `limit` (1–200, default 50) and `cursor`, and returns `data`, `next_cursor` and `has_more`. Follow `next_cursor` while `has_more` is true. Most also take `from` and `to`, inclusive and UTC.

There is no `environment` parameter, deliberately: a credential belongs to one environment and the history you get is its own. A test key cannot read live records.

## Rounds

`GET /v1/rounds` — auth: operator-api

**Query**

| Name | Type | Meaning |
| --- | --- | --- |
| `player_id` | string | Your own player id. |
| `game` | string | Game slug, e.g. `mines`. |
| `status` | string | `OPEN`, `SETTLED` or `VOIDED`. |
| `free_bet` | true | false | Rounds funded by a free bet — the ones that raise no wallet call. |
| `from / to` | ISO 8601 | On the round start time. |

```json
{
  "round_id": "rnd_45vq2tibskftpz9f6xto",
  "wallet_round_id": "4316deee-b478-434d-a5a7-51a4a6523c37",
  "wallet_game_id": "deef2e01-f65d-4dad-8cc4-5eeebf75b77b",
  "external_round_id": null,
  "player_id": "your_player_42",
  "game": "spin-bottle",
  "game_name": "Spin da' Bottle",
  "status": "SETTLED",
  "stake": "1.00",
  "total_bet": "1.00",
  "total_win": "2.00",
  "currency": "GHS",
  "free_bet": false,
  "outcome": { "angle": "223.9624", "status": "won", "outcome": "up" },
  "fairness": {
    "server_seed_hash": "a02540d7…",
    "client_seed": null,
    "nonce": 1
  },
  "started_at": "2026-09-02T21:15:10.341Z",
  "completed_at": "2026-09-02T21:15:10.439Z"
}
```

**Two fields worth reading twice**

| Name | Type | Meaning |
| --- | --- | --- |
| `stake vs total_bet` | they differ | `stake` is what was staked. `total_bet` is summed from settled BET rows, so it is `"0.00"` on a free bet — no debit was raised. Reconcile against `stake`. |
| `free_bet` | boolean | True means no wallet call exists for this round's stake. A losing free bet has no wallet call at all — see [webhooks](/docs/webhooks). |

## One round, and what it moved

`GET /v1/rounds/{roundId}` — auth: operator-api

Accepts any of the three identifiers for a round — the `rnd_…` handle events carry, the uuid wallet calls carry, or your own `external_round_id`. Returns the object above plus the movements the round caused, so a reconciler settles it in one call:

```json
"transactions": [
  { "type": "BET", "status": "SUCCESS", "amount": "1.00",
    "transaction_id": "rnd_45vq2tibskftpz9f6xto.bet", "created_at": "…" },
  { "type": "WIN", "status": "SUCCESS", "amount": "2.00",
    "transaction_id": "rnd_45vq2tibskftpz9f6xto.win", "created_at": "…" }
]
```

> **An empty list is not a fault**
>
> A settled round with no transactions is a losing free bet: nothing was owed and nothing was called. That is the case this endpoint exists to let you prove.

## Voiding a stuck round

`POST /v1/rounds/{roundId}/void` — auth: operator-api

A round is created before its stake is taken, so if the debit fails the round can be left `OPEN`. A player may hold one open round per game — a round open in Mines never blocks Dice — so a stranded round locks them out of that one game until it is cleared. This releases it.

```bash
curl -X POST https://api.casinoapipro.com/v1/rounds/rnd_8mmde7j8/void \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "debit never completed"}'
```

> **Only for rounds that never took money**
>
> A round with a `SUCCESS` or `PENDING` movement against it is refused with `409`. Those moved real money, or may have, and the answer is a [refund or rollback](/docs/transactions) — which reverses it on both sides — rather than a status change that would strand the difference. Movements that `FAILED` moved nothing and do not block a void.

## Movements

`GET /v1/transactions` — auth: operator-api

The ledger, listed. Filter by `type`, `status`, `player_id`, `round_id` (either identifier) and a date window. Each row carries `wallet_round_id`, so movements join to rounds exactly rather than by timestamp and amount.

```bash
curl "https://api.casinoapipro.com/v1/transactions?type=WIN&from=2026-09-01" \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

## Sessions

`GET /v1/sessions` — auth: operator-api

Filter by `player_id`, `status` (`ACTIVE`, `EXPIRED`, `CLOSED`, `REVOKED`) and a window. Creating one is on [sessions and launch](/docs/sessions).

## Players

`GET /v1/players` — auth: operator-api

`GET /v1/players/{playerId}` — auth: operator-api

Players we have seen on your account, addressed by your own id. `q` substring matches. For a player's money position rather than their record, see [the reporting API](/docs/reports).

`player_name` is the display name we hold for them — whatever you last sent on [a session](/docs/sessions), or `null` if you have never sent one. It is here so you can read back what we store rather than infer it from what you sent.

## Free bets

`GET /v1/freebets` — auth: operator-api

Grants held on your account, with `remaining` against `quantity` and the `total_win` they have produced — which is the entire cost of a free bet to you, since no debit is ever raised. Filter by `player_id` and `status` (`ACTIVE`, `SPENT`, `EXPIRED`, `REVOKED`).

`POST /v1/freebets/{grantId}/revoke` — auth: operator-api

Withdraws whatever is left of a grant and answers with `unspent`, the number of bets that will now never be played. Only an `ACTIVE` grant can be revoked; one already spent, expired or revoked is refused rather than quietly accepted.

> **Only the unplayed part**
>
> Free bets already spent have produced rounds, and a round that happened cannot be un-happened. Revoking is not a refund — it stops what has not been used.

## What is still dashboard-only, and why

A few things are deliberately not reachable with an API key, because a key that can do them is a key worth stealing:

- Issuing and revoking credentials. A key that can mint keys turns one leak into permanent access.
- Webhook endpoints. No machine credential should be able to redirect where your events are delivered.
- Wallet configuration. Same argument, with money on the other end of it.
- Team, businesses and billing. These are about people and contracts rather than traffic.

Everything else is either here already or a gap worth reporting. We would rather add an endpoint than have you drive a browser.


Section: Integrate

# Reporting API

> Turnover, GGR, per-game performance and one player's position, for your own systems.

Source: https://casinoapipro.com/docs/reports
Turnover, GGR, per-game performance and one player's position — the same numbers the dashboard shows, for your own BI stack. Authenticated with an ordinary API credential.

> **Available on Growth and above**
>
> A `403` here means your plan does not include the reporting API, and the message names the plan that does. Everything on this page is also visible in the dashboard on every plan — this is about getting it into your own systems.

## There is no environment parameter

A credential is issued for sandbox or for live, and that is the environment its reports cover. Taking it from the query string would let a sandbox key read live figures, which is a data leak dressed up as a filter. Use the credential for the environment you want.

## Windows

Every endpoint takes `from` and `to`, defaults to the last 30 days, and echoes back the window it actually used — a report whose period you have to infer cannot be reconciled against anything. Windows are capped at 366 days; a longer request is refused rather than silently clamped, because a total quietly missing half its rows is worse than an error.

## Summary

```bash
curl https://api.casinoapipro.com/v1/reports/summary \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

```json
{
  "window": { "from": "2026-08-01T00:00:00.000Z", "to": "2026-08-31T00:00:00.000Z" },
  "environment": "SANDBOX",
  "total_bets": "4918.60",
  "total_wins": "4199.92",
  "ggr": "718.68",
  "round_count": 562,
  "active_players": 44,
  "currency_breakdown": [{ "currency": "USD", "bets": "4918.60", "ggr": "718.68" }]
}
```

## Per game

`GET /v1/reports/games`. Each row carries the return players actually got alongside what the game advertises.

```json
{
  "data": [{
    "slug": "dice",
    "rounds": 225,
    "total_bet": "81.30",
    "ggr": "-8.23",
    "realised_rtp": "110.12",
    "advertised_rtp": "97.000"
  }]
}
```

> **Expect these to differ, and do not alert on it**
>
> A month is a small sample for a high-variance game. The advertised figure is a long-run expectation, not a promise about any particular month — a game running 110% over 225 rounds is ordinary. If it persists across tens of thousands of rounds, that is worth a ticket.

## Daily series

`GET /v1/reports/daily` — one row per UTC day with rounds, active players, turnover and GGR. Bucketed in UTC so a day means the same thing in every report you reconcile it against.

Every day in the window is returned, including the ones on which nothing happened. A series that omits its quiet days cannot be told apart from one with rows missing, and anything charting it will draw a straight line through the gap.

## Bucketed series

`GET /v1/reports/series` — the same figures grouped by `granularity=day|week|month`. Omit it and the bucket is chosen from the length of the window; either way the response says which was used, so a caller never has to infer it.

```json
{
  "window": { "from": "2024-01-01T00:00:00.000Z", "to": "2026-09-21T00:00:00.000Z" },
  "currency": "GHS",
  "granularity": "month",
  "data": [{ "date": "2024-01-01", "bets": "0.00", "wins": "0.00", "ggr": "0.00", "rounds": 0 }]
}
```

Weeks start on Monday, in UTC. This endpoint is capped at 400 buckets rather than at 366 days: a monthly series over five years is sixty rows and costs less to serve than a year of daily ones, so a day limit would have refused the cheap request and allowed the expensive one.

## How far back the data goes

`GET /v1/reports/bounds` — the first and last settled activity for the credential&rsquo;s environment, as `first` and `last`, or `null` on an account that has not traded yet. It is what &ldquo;all time&rdquo; means: without it, asking for everything means guessing a start date, and guessing early means asking us to scan years that never existed.

## One player

`GET /v1/reports/players/:playerId`, addressed by your own player id — the one you supplied when you created the session, not ours. Requiring you to store and map our uuid to call your own reporting would be a join we imposed on you for no reason.

```bash
curl "https://api.casinoapipro.com/v1/reports/players/player-42?include_rounds=true&limit=100" \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

With `include_rounds`, every round carries the mathematics it was settled on:

```json
{
  "position": { "rounds": 101, "total_bet": "50.00", "ggr": "-2.49", "realised_rtp": "104.98" },
  "rounds": {
    "total": 101,
    "data": [{
      "round_id": "rnd_buj5wurfbuh6kkqzvjrf",
      "game": "dice",
      "bet": "40.00",
      "win": "42.80",
      "release": "1.0.0",
      "release_rtp": "97.000",
      "server_seed_hash": "24728ed9fc41…",
      "played_at": "2026-08-31T01:45:59.000Z"
    }]
  }
}
```

`release` and `server_seed_hash` are what make a disputed round answerable: the first says which certified parameter set paid it, the second lets the player verify the draw themselves.

## Money is strings

Every amount is a decimal string, never a float. These numbers go into ledgers and invoices; handing back a value that has already lost precision, for you to parse into another float, is how two systems end up disagreeing by a cent and neither can say which is right. Parse them with a decimal type.

## Your account&rsquo;s audit log

`GET /v1/reports/audit` — every recorded action on your account, newest first: sign-ins, role changes, key rotations, invitations, plan activations. `action` is a prefix, so `team.` returns the whole family and `dashboard.login` returns just the sign-ins. Each row carries who did it, what they did it to, the source address, and a `metadata` object holding the before and after.

Secrets are redacted where each entry is written rather than on the way out — a password change records _that_ it happened and never what it became — so what you read here is the whole record, not a filtered view of one.

```bash
curl "https://api.casinoapipro.com/v1/reports/audit?action=team.&limit=20" \\
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

## Throughput

- 60 requests a minute, well under the transaction endpoints — a runaway BI job must not crowd out live play.
- Reports are aggregates over your whole history. Cache them; do not poll them per page view.


Section: Integrate

# Promotions and tournaments

> Free bets, rain, cashback, referrals and tournaments — and why they all pay in free bets.

Source: https://casinoapipro.com/docs/engagement
Free bets, cashback, referrals and tournaments. All four are configured from the dashboard and all four are driven by the same rule, which is worth stating once at the top.

> **Every promotion pays in free bets, never in cash**
>
> We do not hold your float. A cash credit issued by us would be money promised on your behalf with nothing behind it, so promotions grant free bets instead — already backed, already expiring, and already reported separately so you can see what a campaign cost. Every computed amount is also exposed, so if you would rather pay cash you can read the figure and pay it through your own wallet.

## Free bets

A grant is a number of bets at a fixed stake, optionally scoped to one game and optionally expiring. The player sees them in the game menu and picks one before staking; the stake is then the grant's, not the stepper's.

- A grant scoped to a game cannot be spent at another table. This is enforced when it is listed and again when it is spent.
- Spending is a conditional update, so two tabs cannot spend the same bet twice.
- `total_win` on the grant is what the promotion has paid out — the cost of the campaign, separate from your ordinary GGR.

## Rain

A burst of free bets dropped into a game's chat room for anyone watching to claim, first come first served. Claiming is a unique index plus a conditional decrement inside one transaction, so a drop of ten is claimed by exactly ten people however many tap at once.

## Cashback

A standing rule that returns part of a player's net loss over a period. Set the percentage, the period, a minimum loss to qualify and a cap per player.

| Name | Type | Meaning |
| --- | --- | --- |
| `percent` | decimal | Share of net loss returned. Rounded down to two places — a promotion should never pay more than it advertises. |
| `period` | DAILY | WEEKLY | MONTHLY | Weeks are anchored to Monday 00:00 UTC, not "seven days ago". |
| `min_loss` | decimal | Below this, nothing is awarded. Stops a rule issuing thousands of one-cent grants that cost more to process than they are worth. |
| `max_award` | decimal | The most one player can receive from one run. This is what bounds a bad week. |

> **Running a period twice pays nobody twice**
>
> A run claims its window before it computes anything, so a duplicate cron, a second node, or somebody pressing Run now twice reports `already_run` and awards nothing. Weekly windows anchor to a fixed weekday for the same reason: a sliding window makes Tuesday's run and Wednesday's run two different windows that overlap, and both would pay for the days in the overlap.

## Referrals

A player shares a code; when the player who used it has staked the qualifying turnover, both sides are paid.

> **Nothing is paid on signup, and a zero threshold is refused**
>
> A referral bonus that pays for an account existing is a bounty on account creation, and it is farmed within days of launch. The reward needs turnover the referred player actually staked. `max_per_referrer` bounds what one person with a bot farm can take.

## Tournaments

A scheduled window, a scoring rule and a prize table. Leaderboards update as rounds settle and prizes are awarded automatically when the window closes.

| Name | Type | Meaning |
| --- | --- | --- |
| `TOTAL_WAGERED` | scoring | Rewards volume. Your biggest players will win it. |
| `NET_WIN` | scoring | Wins minus stakes. Rewards being ahead, and can go negative. |
| `BIGGEST_MULTIPLIER` | scoring | The single best payout-to-stake ratio. One lucky round can win it, so a small player has a real chance. |
| `WIN_COUNT` | scoring | Counts winning rounds. Favours low-risk, high-frequency play. |

These are not interchangeable — a wagering contest and a biggest-multiplier contest produce completely different behaviour from the same players.

> **Set a minimum stake, or the leaderboard is a scripting contest**
>
> Without one, a wagering tournament is won by whoever automates the most one-cent rounds. Rounds under `min_stake` do not score at all.

Prizes are frozen at creation: they cannot change while players are competing for them. Ties break on fewest rounds, then who entered first, so the result is deterministic rather than whatever order the database happened to return.

## What the player's client sees

`GET /v1/game/tournaments` — auth: game-launcher

Live tournaments covering the game the player is sitting at, their own score and rank, and the top of the leaderboard with names masked the same way every other player-visible name on the platform is.

```json
{
  "data": [{
    "name": "Weekend Cup",
    "scoring": "TOTAL_WAGERED",
    "ends_at": "2026-09-07T00:00:00.000Z",
    "min_stake": "1.00",
    "prizes": [{ "rank": 1, "amount": "100.00" }],
    "me": { "score": "16.00", "rounds": 8, "rank": 1 },
    "leaderboard": [{ "rank": 1, "player": "d***3", "score": "16.00", "is_me": true }]
  }]
}
```

A player outside the top ten sees their score and no rank. Computing an exact position would be a count over every entry on every poll, which is not worth it for a number nobody acts on.

Costs land in your ordinary reporting — see [the reporting API](/docs/reports).


Section: Integrate

# Risk and chat

> Fraud signals over your own data, and the moderated room your players talk in.

Source: https://casinoapipro.com/docs/risk-and-chat
Two things that sit between your players and your balance: signals about unusual activity, and the room they talk in.

## Risk signals are rules, not a model

> **This is deterministic scoring over your own data. It is not machine learning.**
>
> We say so here because you may have to explain it to a regulator, and because a queue you cannot reproduce is one you cannot defend. Every signal is a threshold over numbers you can query yourself. If you want the underlying rounds, they are all in [reporting](/docs/reports).

| Name | Type | Meaning |
| --- | --- | --- |
| `VELOCITY` | signal | Rounds arriving faster than a person can plausibly play them. |
| `STAKE_ESCALATION` | signal | A stake far outside this player's own median — not a fixed amount, because 500 is unremarkable for one player and a takeover for another. |
| `WIN_RATE_ANOMALY` | signal | Realised return well above the game's, over enough rounds to be worth a look. |
| `LARGE_PAYOUT` | signal | One payout big enough to warrant a human glance. |
| `BONUS_ABUSE` | signal | Free bets or rain claimed at a rate that suggests farming. |
| `MULTI_ACCOUNT` | signal | Several accounts from one address. Shared connections are ordinary, so this is low by default. |
| `WALLET_FAILURES` | signal | A burst of wallet failures: your integration faulting, or somebody probing it. |

## What it will and will not do

- It never moves money and never blocks a player. A false positive that freezes a real balance costs more than most of the fraud it would catch. Acting is your decision.
- It never delays a bet. Scoring runs after settlement and its failures are logged and dropped — a slow risk query must not look like a declined stake.
- Events deduplicate and only escalate. A bot at ten rounds a second is one row holding the worst observation, not a firehose.

> **A win-rate anomaly is not evidence of anything**
>
> Variance over a few hundred rounds is enormous. It is a prompt to look at the rounds — each of which is individually replayable from its seed — and that replay, not the signal, is where a dispute is actually settled.

Dismissals are recorded in your audit log with who and when. "Who decided this was fine" is the question an investigation opens with.

Available on Growth and above.

## In-game chat

A shared room per game, rendered inside the game frame. Everything below is driven from your own servers — you do not need the console for any of it.

### Turning it off

`PATCH /v1/catalogue/{gameId}` — auth: operator-api

Send `{ "chat_enabled": false }`. Off is a legitimate setting: an operator who cannot supervise a room should not have one, and some markets will not permit player-to-player messaging at all. It is per game rather than account-wide, so a crash table can have a room while everything else does not.

> **It takes effect on the next connection**
>
> A player already sitting at the table keeps their room until they reconnect. If you need somebody silenced right now, that is a mute, which is checked on every message.

## What the filter removes, before anyone sees it

Links, email addresses, phone numbers and messenger handles are stripped from every message as it arrives. A player being talked into moving off-platform is a player being set up to be defrauded, and that conversation is the one thing a casino chat room reliably attracts.

> **Ordering matters, and it bit us**
>
> The link rule originally ran before the email rule, so `joe@evil.com` had its domain stripped and leaked the rest. Email is matched first now. Mentioned because it is the kind of bug that looks like it works right up until it does not.

### Your own word list

`GET /v1/chat/blocklist` — auth: operator-api

`PUT /v1/chat/blocklist` — auth: operator-api

The filter above stops at the mechanical on purpose. Past that point what counts as unacceptable is a decision about your market and your brand — one operator needs a competitor's name gone, another needs religious terms left alone — and it is not a rule we can make on your behalf. So the list is yours: up to 200 words, each up to 40 characters.

| Name | Type | Meaning |
| --- | --- | --- |
| `Whole words only` | rule | Case-insensitive and boundary-matched, so `rival` does not touch `arrival`. Phrases work. |
| `Masked, not withheld` | rule | The word becomes `···` and the sentence survives — proportionate for a list whose reasoning is yours rather than ours. |
| `Evasion is withheld` | rule | A message spelling one of your words as `r1valbet` does not land at all. Writing it that way proves the sender knew. |
| `PUT replaces` | rule | Send the whole list every time. One word replaces the list with that word. |

> **We audit the count, never the words**
>
> A blocklist names what you consider unacceptable, which can be a sensitive fact about the market you are in. The audit trail records that it changed and by how much.

Keep the list short. A withheld message tells the sender only that it did not send — it cannot name your word without handing your list to anyone willing to probe for it. So every word you add is one an honest player can trip with nothing to learn from, and they will simply believe the room ate their message. The rules above earn that silence by being published; a private list cannot, and pays for each entry in players who do not know what they did.

Which makes the useful question not "what would we rather not read" but "what is worth a player being confused by". The mechanical abuse is already gone before you start. What is left is usually smaller than it first appears — and sometimes it is not a word problem at all: a complaint that keeps recurring in the room is a complaint about something, and filtering it is the one response guaranteed not to fix it.

### What the sender is told

A message the filter withholds sends a `chat_rejected` frame back to that player and nobody else, carrying their own text so your client can put it back in the box rather than making them retype it.

| Name | Type | Meaning |
| --- | --- | --- |
| `contact_details` | reason | A link, address, phone number or messenger handle was all the message contained. These rules are published, so naming them helps an honest player rephrase. |
| `not_delivered` | reason | Everything else. A slur and a word on _your_ list are deliberately indistinguishable — a rejection that said which would let a player recover your blocklist one message at a time. |

> **A mute stays silent, and that is different**
>
> A mute is a decision a person made; telling somebody they are muted turns it into an argument with your staff. A withheld message is a rule firing, and if the rule misfires the sender needs to know — otherwise the message vanishes from their side, they assume it sent, and there is nothing for anyone to report. An operator asked us which of those this was. It was the wrong one until 18 September 2026.

## Moderation

`GET /v1/dashboard/chat/messages` — auth: dashboard

Everything said in your rooms, filterable to just what the filter acted on with `?flagged=true`. Messages listed here have already been shown in their filtered form — removing one takes it out of the record, muting stops the next one.

`POST /v1/chat/messages/{messageId}/remove` — auth: operator-api

`messageId` is the `id` the room delivered with the message, so a client can offer a remove button without a lookup. Removal is recorded rather than destructive: the message stays in your review history marked removed.

`POST /v1/chat/mutes` — auth: operator-api

A mute stops somebody talking; it does not stop them playing. Empty duration mutes indefinitely, `0` unmutes. `player_id` takes your own id for the player. Both are audited with the actor and reason.

## What your players reported

`POST /v1/game/chat/report` — auth: game-launcher

`GET /v1/chat/reports` — auth: operator-api

`PATCH /v1/chat/reports/{reportId}` — auth: operator-api

The filter removes what is mechanical. Everything past that is a judgement call, a judgement call needs a person, and a person needs to be told — so a player reports a message from inside the game and it lands in your queue, open first and oldest complaint first.

Each report carries the message, what the filter had already done to it, `message.id` for removal and `message.author_id` for a mute, so you can act on one without another request. Marking a report reviewed records that somebody looked; it does not remove anything or mute anybody, because those stay deliberate acts with their own audit entries.

> **A report is not a vote**
>
> One per player per message, and the player is told only that it was received — never how many others reported it or what you decided. A room moderated by whoever is most organised is not a moderated room.


Section: Reference

# Run it from your own servers

> Everything the console can do, driven by an API key: catalogue, tournaments, promotions, risk, chat, the operational record, currencies and support — and the four things that deliberately stay behind a person.

Source: https://casinoapipro.com/docs/automation
Everything your team does in the console, your servers can do with an API key. Not a parallel implementation — the same code, with your credential recorded as the actor instead of a person, so the two cannot validate different things or audit differently.

Use the same bearer token as the rest of the API: see [Authentication](/docs/authentication). Everything on this page is scoped to the account the key belongs to, so no endpoint takes an operator id.

## Your catalogue

`GET /v1/catalogue` — auth: api key

Your games rather than the public list: what is enabled, the release each game is pinned to, and the return that release actually pays. `POST /v1/catalogue/{gameId}/rtp` retunes the return, and `PATCH /v1/catalogue/{gameId}` takes everything the console does:

**PATCH body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `enabled` | boolean | no | Whether players can launch it at all. |
| `min_bet / max_bet` | string | null | no | Your stake limits. Null clears the override and returns the game to the platform's own limit; absent leaves it alone. |
| `max_win` | string | null | no | The most a single round may pay. Can only narrow the platform cap, never widen it — that ceiling is our risk budget rather than yours, so raising it stays an admin action. |
| `release_id` | uuid | null | no | Which certified release your players get. Must belong to this game and not be retired. Null returns you to the platform default. |
| `thumbnail_url` | string | null | no | Your own artwork. Must be `https://` — the tile renders on a TLS page, so a plain-http image is blocked as mixed content and shows blank. |
| `chat_enabled` | boolean | no | Whether the room has chat. |
| `demo_players` | integer | no | Ambient players on the shared-round feed. Presentation only; 0–400. |
| `feedback_enabled` | boolean | no | Whether players can rate the game. |
| `limits` | object | no | Per-currency limits, keyed by ISO 4217 — see below. A currency mapped to `null` clears its override. |

## Limits on a multi-currency account

`min_bet`, `max_bet` and `max_win` above carry no currency: they are compared directly against the stake. On a single-currency account that is exactly right. On an account holding two currencies two orders of magnitude apart it is not — a floor of `"0.50"` means 0.50 in both, and no single value is sensible for either.

So `limits` sets them per currency. Fields are independent: an entry with only `min_bet` leaves the game's own maximum in force for that currency. A currency with no entry behaves exactly as it always has.

```bash
curl -X PATCH https://api.casinoapipro.com/v1/catalogue/$GAME_ID \\
  -H "Authorization: Bearer $TOKEN" \\
  -H "Content-Type: application/json" \\
  -d '{
    "limits": {
      "GHS": { "min_bet": "0.50", "max_bet": "5000" },
      "NGN": { "min_bet": "500",  "max_bet": "50000" },
      "USD": null
    }
  }'
```

`GET /v1/catalogue` returns them under the same key, so you can read back what we hold rather than infer it from what you sent.

> **These narrow, and a ceiling above ours is still a conversation**
>
> A per-currency limit is bounded by the same platform figures as the flat one, and that ceiling does not itself vary by currency yet. So you can raise a floor in a large-denomination currency freely — which is the half that was missing — but a maximum above the platform's own is refused, because it spends our exposure rather than yours. Ask us and we will look at it.

> **Nothing is converted**
>
> We do not hold a rate and never will: an exchange rate in the bet path is a number that goes stale and then silently moves every limit on your account. These are the figures you set, in the currency you set them in.

> **Limits are checked against the release you are moving to**
>
> If you change `release_id` and the stake limits in one request, the limits are validated against the _incoming_ release, not the one you are leaving. A minimum above the maximum, or a maximum win below the maximum bet, is refused rather than clamped — silently clamping means the number you typed is not the number you got.

> **The rtp you get back is the one that pays**
>
> Asking for 94% builds a configuration and the response tells you what that configuration actually returns, which can differ once multipliers are floored. Advertise the number in `rtp`, not the one in `asked`.

It is `/v1/catalogue` and not `/v1/games` because the launcher already owns `/v1/games` with a player token. The name is better anyway: this is _ your_ catalogue, and `/v1/public/games` is the platform's.

## Promotions on a schedule

`POST /v1/promotions/cashback/{ruleId}/run` — auth: api key

A weekly cashback period is a cron job, not a button. Create the rule once with `POST /v1/promotions/cashback`, then run it from your own scheduler.

> **Safe to call twice**
>
> The run claims its window before computing anything, so a retry over the same period answers `already_run: true` and pays nobody. This matters more from a machine than from a button, because a machine retries on a timeout.

Referrals are a single settings row: `POST /v1/promotions/referrals`. Rain drops free bets into a game's chat for anyone to claim — `POST /v1/rain` — and claims are race-safe, one per player with the total capped in the same transaction.

> **Both pay in free bets, never cash**
>
> We do not hold your float, so a cash credit issued here would be money promised on your behalf with nothing behind it. Read the computed amounts and pay cash through your own wallet if that is what you want.

## Tournaments

`POST /v1/tournaments` — auth: api key

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `name` | string | yes | Shown to players on the leaderboard. |
| `scoring` | enum | no | One of `TOTAL_WAGERED`, `NET_WIN`, `BIGGEST_MULTIPLIER`, `WIN_COUNT`. |
| `starts_at / ends_at` | timestamp | yes | Must end after it starts, and must not already have ended. |
| `game_ids` | uuid[] | no | Empty means every game in your catalogue. Each must be in it. |
| `prizes` | object[] | yes | One entry per rank. Ranks must be distinct — see below. |

> **Two prizes at rank 1 is not a tie**
>
> It is a table where settlement pays whichever row it finds first, and you have no idea which until it happens. Duplicate ranks are refused.

Prizes are frozen at creation: they cannot change once players are competing for them. Cancel with `POST /v1/tournaments/{id}/cancel`, which works only while the tournament is unsettled — a finished tournament has already paid, and un-happening that would leave grants in players' accounts for a competition we claim never ran.

`GET /v1/tournaments` returns yours plus the network tournaments your players can enter; `editable` tells you which are yours.

`GET /v1/tournaments/{tournamentId}/leaderboard` — auth: api key

Standings, ranked, with `prize` and `awarded_at` filled in once a tournament has settled. On a network leaderboard only your own players are named — `is_yours` marks them, and another operator's player ids and turnover are not ours to hand over.

## The risk queue

`GET /v1/risk/events` — auth: api key

Signals, sorted worst-first, so the thing most worth looking at is never on page three. Mark one reviewed or dismissed with `PATCH /v1/risk/events/{eventId}`.

> **A signal is a prompt to look, not a finding**
>
> These are deterministic rules, not machine learning, and nothing on this surface blocks a player or moves money. Dismissals are audited against the credential that made them: “who decided this was fine, and when” is the question an investigation opens with.

## Chat moderation

`POST /v1/chat/mutes` — auth: api key

`GET /v1/chat/messages?flagged=true` is the review queue — the messages the filter acted on, with the reason it acted. Mute a player for a number of minutes, or pass `minutes: 0` to unmute. `player_id` accepts your own id for the player, which is what `GET /v1/players` returns.

`POST /v1/chat/messages/{messageId}/remove` — auth: api key

Takes one message out of the room. It is scoped to your account in the lookup itself, so a guessed id from another operator answers `404` rather than removing anything. Removal is recorded, not destructive — the message stays in the record marked removed.

## The operational record

| Name | Type | Meaning |
| --- | --- | --- |
| `GET /v1/api-logs` | endpoint | What we saw you send — the first thing to check against what you believe you sent. |
| `GET /v1/rounds/{roundId}/wallet-calls` | endpoint | The other direction: every call we made to _your_ wallet on a round, with your own response body verbatim. See below. |
| `GET /v1/webhook-deliveries` | endpoint | Every delivery, its attempt count, response status and error. |
| `POST /v1/webhook-deliveries/{id}/retry` | endpoint | Delivers now and returns the result, so a script draining a backlog after an outage knows whether it worked. |
| `GET /v1/sla` | endpoint | Uptime and response times against your plan, with the platform-wide figure beside yours. |
| `GET /v1/feedback` | endpoint | Player ratings and comments on your games. |
| `GET /v1/notifications` | endpoint | Account-wide notices. A key has no inbox of its own, so anything addressed to one person stays theirs. |
| `POST /v1/notifications/read` | endpoint | Marks them read. Send `ids` to mark specific ones, or no body at all to mark everything. |

## Is the shared flight in the air

`GET /v1/catalogue/{gameId}/flight` — auth: api key

For Goal Jet and anything else where one round is shared across your players. The flight sleeps after about two minutes with nobody playing and wakes on the next session, so `idle` is normal rather than a fault — `idle_seconds` says how long, and `never_flown` means no round has ever run on your account.

> **Reading this does not wake it**
>
> Which is the point. The only way to see a flight used to be to mint a session and look through it, which both spends a session you may not use and starts the thing you were trying to measure — so a stopped flight could not be observed without ending the outage you were trying to confirm.

## Reconciling a round

`GET /v1/rounds/{roundId}/wallet-calls` — auth: api key

`/v1/api-logs` is what you sent us. This is the reverse, and it is the one you want when a round is disputed: every movement we raised on it, the request as we put it to your wallet, and your wallet's response body exactly as it came back — including `wallet_reference` and the `balance` it reported.

Addressed by your own round id or by our reference, so you can start from whichever you are holding.

> **attempts above 1 is a retry, not a second movement**
>
> We retry a call that gave us no usable answer — a timeout, a 502 — always with the same `transaction_id`. That is what makes the retry safe, and why your wallet should answer the second one with `duplicate: true` and move no money. A round showing `attempts: 3` and one movement is that working.

## Currencies

`PATCH /v1/business` — auth: api key

A session in a currency your account does not hold is refused with `CURRENCY_NOT_SUPPORTED`, and this is how you add one without asking us.

```bash
curl -X PATCH https://api.casinoapipro.com/v1/business \\
  -H "Authorization: Bearer $TOKEN" \\
  -H "Content-Type: application/json" \\
  -d '{"currencies":["USD","NGN","GHS"]}'
```

> **Removing a currency players are registered in is refused**
>
> It would strand them: their sessions would start failing and there is no way back. Refused rather than cascaded — these are your players, and we do not get to decide which of them to break.

## Sandbox wallets

`POST /v1/sandbox/players` — auth: api key

Play money, with no relationship to real funds. This is what makes an automated integration test possible: set a known balance, play, assert on the result.

## Support

`POST /v1/tickets` — auth: api key

Useful from a monitor: the alert that noticed the problem can open the ticket about it. The ticket is labelled with the key that raised it, and we reply to your account owner — a credential has no address of its own.

`GET /v1/tickets/{ticketId}` — auth: api key

One ticket and its conversation in order. Our internal notes are never included: those are support talking to support, and they do not belong on your side of the thread.

`POST /v1/tickets/{ticketId}/reply` — auth: api key

Adds a message and moves the ticket back to `AWAITING_SUPPORT`. A closed ticket is refused — open a new one rather than reviving a thread we have finished with.

## What a key deliberately cannot do

Four things stay behind a person who has signed in. The test is not whether something is tedious in a browser — it is what an attacker gets if the key escapes.

- **Issuing, rotating or revoking credentials.** A key that can mint keys turns one leak into permanent access, and one that can revoke them can lock you out of your own account.
- **Creating or repointing webhook endpoints.** Where your events go is worth stealing. Reading the delivery log and retrying a delivery is on this side of the line; changing the destination is not.
- **Configuring your wallet.** This is the outbound money path. A key that can change the base URL can redirect every debit and credit on the account.
- **Team and billing.** Who may act on your account is a people decision, and a key that can promote a member could promote itself to owner.

> **This list is enforced by a test, not by a promise**
>
> A test reads both surfaces out of the source and fails if a console capability has no API counterpart and no stated reason. A new console feature that forgets the API is a broken build rather than a support ticket six months later.


Section: Reference

# Team and account

> Roles, invitations, several businesses under one login, brands, tickets and setting your own RTP.

Source: https://casinoapipro.com/docs/account
Who can sign in, how many casinos you run under one login, and how to reach us when something is wrong. All of this is in the dashboard; the endpoints are here because some of you will want to drive it from your own tooling.

## Team and roles

`GET /v1/dashboard/team` — auth: dashboard

| Name | Type | Meaning |
| --- | --- | --- |
| `OWNER` | role | Full control, including roles, billing and creating another business. |
| `ADMIN` | role | Can change settings and invite people. Cannot change roles, and cannot invite an owner. |
| `ANALYST` | role | Can see everything. Cannot change anything. |

> **An account always keeps one active owner**
>
> The last owner cannot be demoted or disabled. Without that rule an owner can lock the whole account out — nobody left who can invite, change a role, or undo it, and the only fix is us editing the database. Promote somebody else first.

An `ADMIN` cannot invite an `OWNER`: granting yourself more than you have, via somebody else, is not a thing the roles should permit.

## Invitations

`POST /v1/dashboard/team/invites` — auth: dashboard

An invitation is a row, not an account — the person may not exist yet and must not get one they never accepted. Links expire after seven days and work once. The token is stored hashed: an invitation link is a credential, and a database leak should not hand somebody a way into your console.

The response includes the link as well as sending it, so an invitation still works on a deployment where outbound email is not configured.

> **Outstanding invitations count against your seats**
>
> Otherwise an account on a three-seat plan could invite twenty people and fill up as they arrived. Revoke the ones you are not waiting on.

## More than one business

`GET /v1/dashboard/businesses` — auth: dashboard

One login, several casinos. Each is a separate account with its own games, players, credentials, brands and reporting — they share nothing but you. The switcher at the top of the console splits them into the ones you own and the ones you were invited onto.

Switching mints a token for your membership _on that account_, so the role that applies is the one you hold there, which may be lower than the one you hold here.

## Currencies

`PATCH /v1/dashboard/businesses/{operatorId}` — auth: dashboard

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `currencies` | string[] | no | ISO 4217 codes the account accepts, e.g. `["GHS","NGN"]`. Replaces the list, so send the full set. |
| `name` | string | no | Rename the business. |
| `country` | string | null | no | Two-letter code, or null to clear. |

Your account&rsquo;s list is the only one that decides this. Every game accepts every currency your account holds — there is no per-game list to be added to and nothing to ask us for. A session in a currency the account does not carry is refused with `422 CURRENCY_NOT_SUPPORTED`; one in a currency it does carry opens, whatever the game is.

Codes are validated against ISO 4217 when you set them, so a typo is refused here rather than surfacing later as sessions failing in a currency that does not exist. `GET /v1/public/currencies` lists every code we accept, with its minor units. The `currencies` field on `GET /v1/games` reports your account&rsquo;s list, because that is the question anyone reading it is asking.

> **Adding is immediate; removing is not always allowed**
>
> Adding a currency takes effect on the next session. Removing one is refused with `409` while any player is registered in it — they could not open a session afterwards, and their history would be denominated in a currency the account denies. The error names how many, so close those out first.

> **This used to be a support request, and nothing said so**
>
> Currencies could previously be set only when a business was created. An operator who added a country later got a `422` in production with no documented way to fix it, and the only self-serve route was creating a second business — new credentials, a separate player base, a fresh live approval. That is a migration, not a workaround. It is an endpoint now because it should always have been one.

## Brands

`GET /v1/dashboard/brands` — auth: dashboard

A brand is a themed launcher and its own set of players — the same games under a different name and palette. Pass `brand_id` when creating a session to attach the player and the round to it.

- Suspending a brand keeps its players and rounds. Nothing is deleted, and it stops counting against your plan.
- Reactivating one counts again, so it is refused if you are at your limit.

`PATCH /v1/dashboard/brands/{brandId}` — auth: dashboard

**Body**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `name` | string | no | What players see. The slug never changes — it is in launch URLs. |
| `domain` | string | null | no | The domain this brand launches under. Null clears it. |
| `status` | enum | no | ACTIVE or SUSPENDED. Reactivating is checked against your plan's brand limit. |
| `theme` | object | no | Launcher colours, applied by the game shell. Free-form. |

## Support tickets

`POST /v1/dashboard/tickets` — auth: dashboard

Raised from the console and attached to your account, so we can see your integration, your rounds and your logs without you having to describe them.

| Name | Type | Meaning |
| --- | --- | --- |
| `category` | string | One of `GENERAL`, `INTEGRATION`, `BILLING`, `TRANSACTIONS`, `GAMES`, `ACCOUNT`. |
| `priority` | string | `URGENT` means live play is broken or money is at risk. It goes to the top of the queue — please keep it for that. |

Include a round id or a request id if you have one. Every API response carries a [request id](/docs/request-ids) and it takes us straight to the request in the log.

> **Response times depend on your plan**
>
> Starter is 24 hours, Growth 8, Business 4 — and 8, 2 and 1 respectively when marked urgent. Sandbox carries no commitment. What we actually managed is measured and shown to you under [Service level](/docs/service-level).

## Notifications

`GET /v1/dashboard/notifications` — auth: dashboard

Things worth knowing inside the product — a reply on a ticket, a webhook endpoint failing, a plan about to lapse. Deliberately not email: a console that can only tell you by email is one you have to leave to find out what it wants.

Repeated problems collapse into one unread notification carrying the latest detail rather than four hundred identical rows, because a bell nobody opens is worse than no bell. Reading one clears that guard, so a problem that recurs after you have acknowledged it notifies again.

## Setting your own RTP

`POST /v1/dashboard/games/{gameId}/rtp` — auth: dashboard

Type a figure and we generate a certified release for it: the engine's own parameter is turned, the config is hashed, and rounds pin it exactly as they pin any other release.

> **The figure returned is the one the engine computes, not the one you asked for**
>
> Some targets land a hair under once multipliers are floored to two decimals. The response carries both `asked` and `rtp`; the second is what players will actually get back, and it is what the catalogue advertises.

- Available on every plan, for all seven games.
- `goal-jet` included. Its flight is flown per operator, so your RTP is your own — your players' crash points are computed from your `edge` and nobody else's. A change takes effect on your next flight; one already in the air keeps the release it launched on.
- There is a platform floor. Below it a game will not pass certification, and we host it under our name.

Rounds already played are unaffected — they keep the release they were settled on, which is what makes an old round still replayable. See [Provably fair](/docs/provably-fair).


Section: Reference

# Service level

> What we commit to, how availability and response time are measured, and credits.

Source: https://casinoapipro.com/docs/service-level
What we commit to, how it is measured, and what you are owed when we miss it. Your own figures are in the dashboard under Service level, month by month.

## The commitment

| Name | Type | Meaning |
| --- | --- | --- |
| `Sandbox` | none | No availability or response-time commitment. The numbers are still measured and shown to you — they are simply not something you can hold us to. |
| `Starter` | 99.5% · 24h | First reply within 24 hours, 8 when urgent. 10% credited if availability is missed. |
| `Growth` | 99.9% · 8h | First reply within 8 hours, 2 when urgent. 15% credited. Served first under load. |
| `Business` | 99.95% · 4h | First reply within 4 hours, 1 when urgent. 25% credited. Served first under load. |
| `Enterprise` | agreed | Written into the contract, including response times. |

## How availability is measured

From your own request log — what your traffic actually did — not from a probe hitting our health check. A probe measures whether one endpoint answered one caller, which is why most status pages stay green during outages their customers can see.

- 5xx counts against us. We broke, or something we depend on did.
- 4xx does not. That is a request we refused because it was malformed or not permitted. Counting it would mean your own integration bug earned you credits.
- 429 does not. The rate limiter working is a capacity conversation, not an outage.

> **No traffic means no measurement, not 100%**
>
> A month in which you made no requests reports no figure rather than a perfect one. Inventing a number there is exactly the kind that gets quoted back when a real month goes wrong.

## How far back it goes

Request logs are kept for thirty days — they are a debugging aid and the fastest-growing table we hold. Availability is therefore rolled up daily, a few hours after each day closes, so months outlive the log they were measured from. A month is a sum of days and is kept indefinitely; the console shows the last twelve.

> **A month we cannot fully account for is not a monthly figure**
>
> Where part of a month predates what we hold, the report says what fraction it could see and no breach is declared and no credit calculated from it. A number computed from half a month is not a monthly result, and presenting one as if it were is worse than saying we cannot tell you.

This mattered in both directions before the rollup existed. A month past the thirty-day horizon reported zero requests, which read as &ldquo;you did not trade&rdquo; rather than &ldquo;we no longer hold the evidence&rdquo;; and the previous month — the one that carries a credit — was computed from whatever fraction of it had survived pruning.

## How response time is measured

From the moment a ticket is raised to the first reply _a person can read_. Internal notes we leave for each other are excluded deliberately — writing one is not answering you, and counting it would make the number look good while nobody had replied.

## Credits

When a month misses the availability target, the dashboard shows the shortfall and the amount owed. Raise a ticket and we apply it.

> **Credits are not applied automatically yet**
>
> We compute and display them; you still have to ask. We would rather you did not, and are working on it. Saying so here beats letting you discover it.

## What "served first under load" means

When the platform is under more load than it can serve, it sheds traffic rather than falling over — and it sheds from the bottom: unauthenticated traffic first, then Sandbox and Starter, and only past its own capacity anything above that. Shed requests get a `503` with `Retry-After`.

Settlement is never shed, on any plan. Wins, refunds, rollbacks and crash cash-outs always complete. Refusing a bet is survivable; refusing the win that follows one would leave a player short and a ledger half-written. Health and status are never shed either.

Your client must treat a 503 as retryable — see rate limits.


Section: Reference

# Error codes

> Every error code the API returns, its status, and whether retrying can help.

Source: https://casinoapipro.com/docs/error-codes
Every code the API returns, what it means, and whether retrying can help. The envelope is described in [Errors](/docs/errors).

> **Retryable is a field, not a guess**
>
> Each error carries `retryable`. Only five codes ever set it true — `WALLET_TIMEOUT`, `WALLET_UNAVAILABLE`, `RATE_LIMITED`, `SERVICE_UNAVAILABLE` and `INTERNAL_ERROR` — and they are marked below. Branch on the field rather than on the status: a `409` is never worth repeating, and a `504` always is, with the same `transaction_id`.

## Authentication and access

| Name | Type | Meaning |
| --- | --- | --- |
| `UNAUTHORIZED` | 401 · no retry | Missing or malformed Authorization header. |
| `INVALID_CREDENTIALS` | 401 · no retry | The key and secret pair did not match, or the token failed verification. |
| `TOKEN_EXPIRED` | 401 · no retry | Mint a fresh token and repeat the request. Not marked retryable because the identical request would fail again — you must get a new token first. |
| `INVALID_SIGNATURE` | 401 · no retry | An HMAC signature you sent us did not verify. |
| `IP_NOT_ALLOWED` | 403 · no retry | Source address outside the credential’s allowlist. |
| `FORBIDDEN` | 403 · no retry | Authenticated, but not permitted — your role, or a capability your plan does not include. The message names the plan that would allow it. |
| `INSUFFICIENT_SCOPE` | 403 · no retry | The token is valid but was minted for another audience — a launch token used against the operator API, say. See [token audiences](/docs/authentication#audiences). |

## Account state

| Name | Type | Meaning |
| --- | --- | --- |
| `OPERATOR_SUSPENDED` | 403 · no retry | The account is suspended. Contact support. |
| `OPERATOR_NOT_LIVE` | 403 · no retry | A live-only operation on an account whose real-money play is suspended. |
| `REAL_MONEY_DISABLED` | 403 · no retry | Real-money play is switched off — either platform-wide, or suspended on your account. The message says which; only one of them is something you can act on. |
| `BRAND_NOT_FOUND` | 404 · no retry | No such brand on this account. |
| `PLAYER_BLOCKED` | 403 · no retry | Your own wallet refused the player — self-exclusion, a KYC hold, or an unknown player id. |

## Validation

| Name | Type | Meaning |
| --- | --- | --- |
| `VALIDATION_ERROR` | 422 · no retry | A field is missing or the wrong shape. Carries `details` naming each offending path — a JSON number where a decimal string was required is the usual cause. |
| `CURRENCY_NOT_SUPPORTED` | 422 · no retry | The currency is not enabled for your account. Games do not restrict currencies — add it with PATCH /v1/business and the next session opens. |
| `CURRENCY_MISMATCH` | 422 · no retry | The movement currency differs from the session currency. |

## Money

| Name | Type | Meaning |
| --- | --- | --- |
| `INSUFFICIENT_FUNDS` | 402 · no retry | Your wallet refused: balance below the stake. Nothing moved. |
| `BET_LIMIT_EXCEEDED` | 422 · no retry | Stake outside the min/max configured for the game on your account. |
| `TRANSACTION_CONFLICT` | 409 · no retry | The same `transaction_id` arrived again with a different body. Fix the caller; nothing moved. Retrying can only conflict again. |
| `TRANSACTION_NOT_FOUND` | 404 · no retry | No movement with that id on this account — including a `reference_transaction_id` on a refund or rollback that names nothing. |
| `TRANSACTION_ALREADY_REVERSED` | 409 · no retry | The original movement has already been refunded or rolled back. |

## Your wallet

These describe your wallet’s behaviour, not ours. See [wallet integration](/docs/wallet).

| Name | Type | Meaning |
| --- | --- | --- |
| `WALLET_TIMEOUT` | 504 · retry | Your wallet did not answer in time. The transaction is left pending and the outcome is genuinely unknown — retry with the same `transaction_id`. |
| `WALLET_UNAVAILABLE` | 503 · retry | We could not reach your wallet at all. Same treatment as a timeout. |
| `WALLET_REJECTED` | 502 · no retry | Your wallet refused with a code we do not recognise, or one that is terminal. The raw code is preserved on the transaction record. |
| `WALLET_NOT_CONFIGURED` | 503 · no retry | No active wallet integration for this environment. Most often a live key against an account that has only configured a sandbox wallet — the two are separate records and one never falls back to the other. |

## Games, sessions and rounds

| Name | Type | Meaning |
| --- | --- | --- |
| `GAME_NOT_FOUND` | 404 · no retry | No such game, or it is not in your catalogue at all. |
| `GAME_NOT_ENABLED` | 403 · no retry | The game is in your catalogue but switched off for you. |
| `GAME_UNAVAILABLE` | 503 · no retry | The game exists and is enabled, but is down platform-wide right now. |
| `SESSION_NOT_FOUND` | 404 · no retry | Unknown session, or it belongs to another operator. |
| `SESSION_EXPIRED` | 410 · no retry | The session passed its expiry. Create a new one. |
| `SESSION_CLOSED` | 410 · no retry | The sitting has ended. |
| `ROUND_NOT_FOUND` | 404 · no retry | Unknown round id. |
| `ROUND_IN_PROGRESS` | 409 · no retry | One open round per player _per game_ — a round open in one game never blocks another. If it will not clear, the round was opened but its stake never taken; void it with [`POST /v1/rounds/{roundId}/void`](/docs/history#void). |
| `ROUND_ALREADY_SETTLED` | 409 · no retry | The round has already reached a terminal state; no further action is possible. |

## Platform

| Name | Type | Meaning |
| --- | --- | --- |
| `RATE_LIMITED` | 429 · retry | Too many requests. Honour `Retry-After` and add jitter. See [rate limits](/docs/rate-limits). |
| `NOT_FOUND` | 404 · no retry | No route, or a resource outside your account. We do not distinguish the two — see below. |
| `CONFLICT` | 409 · no retry | The resource already exists. |
| `INTERNAL_ERROR` | 500 · retry | Our fault. Retry; quote the request id if it persists. |
| `SERVICE_UNAVAILABLE` | 503 · retry | Briefly unable to serve, or shedding load under saturation — see [rate limits](/docs/rate-limits#503). Always retryable. Settlement is never shed. |

> **404 rather than 403 for another operator’s data**
>
> Asking for a session, round or transaction that belongs to someone else returns `NOT_FOUND`, not `FORBIDDEN`. Answering “forbidden” would confirm the resource exists, which leaks the shape of other tenants’ data to anyone willing to enumerate ids. Absence and denial look identical from outside.


---

# Engineering notes

## How a provably fair crash round is actually generated

Source: https://casinoapipro.com/blog/provably-fair-crash-explained
Published: 2026-09-21
Summary: A crash multiplier is derived from a hash of a server seed the operator committed to before the round, combined with a client seed the player controls. Publish the commitment first and anyone can check afterwards that the result was not chosen.

### The problem it solves

A player cannot see your random number generator. They have to take your word that the 1.02x they got was not chosen because they had staked more than usual. "Provably fair" is the arrangement that removes the need to take anybody's word for it.
It works by making the operator commit to the outcome before knowing the stake, and by making that commitment checkable afterwards. Nothing about it requires trusting the operator, the player, or us.

### The three inputs

- A **server seed**, generated by us and kept secret until the round ends. Its SHA-256 hash is published before the round opens: that hash is the commitment.
- A **client seed**, which the player sets and can change whenever they like. This is what stops us from choosing a server seed that produces a convenient result, because we would have to know the client seed first.
- A **nonce**, the round number for that pair of seeds. It makes each round in a sequence distinct without needing new seeds every time.

### Turning a hash into a multiplier

The three inputs are concatenated and hashed. The first bytes of that hash are read as an integer and mapped onto a distribution whose expected return matches the game's published RTP.
The house edge lives in exactly one place: a small share of outcomes is forced to the lowest multiplier. Everything else follows from the hash. That is what makes the maths auditable — there is one constant to check, not a model to trust.

```javascript
// The verification, in full. Nothing here is specific to us.
const crypto = require('node:crypto');

function crashPoint(serverSeed, clientSeed, nonce, houseEdge = 0.01) {
  const h = crypto
    .createHmac('sha256', serverSeed)
    .update(`${clientSeed}:${nonce}`)
    .digest('hex');

  // The instant-bust share. This is the house edge, and it is the only
  // number in the scheme that is a choice rather than a consequence.
  const bustChance = Math.floor(2 ** 52 / houseEdge);
  if (parseInt(h.slice(0, 13), 16) % bustChance === 0) return 1.00;

  const r = parseInt(h.slice(0, 13), 16) / 2 ** 52;
  return Math.floor((100 * (1 - houseEdge)) / (1 - r)) / 100;
}
```

### What to check, as a player

After a round, the server seed is revealed. Three things must hold, and all three are arithmetic rather than opinion:
- The SHA-256 of the revealed server seed equals the hash published before the round.
- Running the function above on the revealed seed, your client seed and the nonce reproduces the multiplier you saw.
- The nonce increased by exactly one since your last round on that seed pair.
If any of those fails, the result was changed after the fact. If all three hold, it could not have been.

### Where this is weaker than it sounds

Provable fairness proves that a specific round was not tampered with. It does not prove the house edge is what was advertised, and it does not prove the operator is solvent. Those are different questions and it is worth being honest that one scheme does not answer all three.
The edge is checkable a different way: play enough rounds and the distribution is what it is. Publish the constant, and anybody with the round history can test it. We publish ours on [every game page](/games) for that reason.

## What a casino wallet integration actually has to do

Source: https://casinoapipro.com/blog/wallet-integration-what-it-actually-requires
Published: 2026-09-21
Summary: Five endpoints: balance, debit, credit, refund and rollback. The only hard requirement is that debit and credit are idempotent on the transaction id you are given — everything else is detail.

### The direction of travel surprises people

You call the games API to [open a session](/docs/sessions). From then on, we call you. Every bet is a request from us to your wallet, and your wallet is the authority on whether the player could afford it.
This is the opposite of the arrangement most integrations assume, and it is the right way round: you keep the balances, the KYC, the deposits and the player relationship. We never hold a player balance, which means there is nothing of your players' money on our side to reconcile, lose or be asked about.

### The five calls

- **balance** — what has this player got? Moves nothing, safe to retry, safe to call against production.
- **debit** — a bet. Must fail if the balance is insufficient, and that failure is a normal outcome rather than an error.
- **credit** — a win.
- **refund** — a specific earlier debit could not be honoured; give it back.
- **rollback** — void an earlier movement in full. Always the full value; there is no partial rollback, because a partial one is a second transaction wearing the wrong name.

### Idempotency is the whole contract

Networks fail after your wallet has committed and before we hear about it. When that happens we retry with the same transaction id, and your wallet must recognise it and move no money the second time. The [full wallet contract](/docs/wallet) writes out every field on the wire.
Answer the replay with the resulting balance and `duplicate: true`. That flag is optional and worth setting: it lets both sides tell a genuine second bet from a retry of the first, which is the difference between a reconciliation that takes a minute and one that takes a week.

```json
POST {your_base_url}/wallet/debit
{
  "transactionId": "bet_9f21c4",
  "playerId": "your_player_42",
  "amount": "10.00",
  "currency": "GHS"
}

// Your answer, first time and every time after:
{ "balance": "489.50", "currency": "GHS" }

// The same id arriving again — no money moves:
{ "balance": "489.50", "currency": "GHS", "duplicate": true }
```

### Refusing a bet properly

Answer with a non-2xx and a code. Insufficient funds is not an error in your system or ours — it is the most common legitimate answer a wallet gives, and it should be fast.
The codes worth mapping are insufficient_funds, player_blocked, player_not_found, currency_mismatch, transaction_not_found and already_reversed. Anything we do not recognise is treated as a terminal rejection and preserved verbatim in the transaction record, so an unmapped code is diagnosable rather than lost.

### Test it before your first real bet

Two things are worth proving before you take a player: that a replayed transaction id moves money once, and that an insufficient balance is refused cleanly rather than timing out.
Both are testable against [a sandbox](/signup) in an afternoon. Neither is testable for the first time on a Saturday night with real players on the platform, which is when integrations that skipped this discover the answer.

## RTP, house edge and the number operators should actually check

Source: https://casinoapipro.com/blog/rtp-house-edge-honestly
Published: 2026-09-21
Summary: RTP is the long-run share of stakes returned to players; the house edge is what is left. The number worth checking is not the advertised RTP but whether the running game reproduces it — which requires the operator to be able to see their own round history.

### The definitions, briefly

RTP is the proportion of everything staked that a game returns to players over a very large number of rounds. A 97% game returns 97 units for every 100 staked, in the limit.
The house edge is the remainder — 3% in that example. They are the same fact stated from two directions, and any source that treats them as separate levers is confused.
Volatility is a different axis entirely. Two games can share an RTP and feel nothing alike: one pays small and often, the other rarely and large. Volatility describes the shape of the distribution; RTP describes its mean.

### Why your last thousand rounds prove nothing

A thousand rounds on a high-volatility game is a small sample. Sitting meaningfully below the published RTP over that span is ordinary, and so is sitting above it. Operators new to this reliably mistake the first for a broken game and the second for luck.
The useful check needs volume and needs to be done per game and per release, because a single RTP figure across a mixed catalogue tells you about your traffic mix rather than about any game.

### The check that matters

A published RTP is a claim until you can test it against your own rounds. That requires two things from a supplier, and it is worth asking for both before you integrate:
- The **RTP of the exact release** a round was played on, not of the game in general. Games get new versions; a figure that is not pinned to a version is not pinned to anything.
- Your **own round history**, in bulk, with stakes and payouts — so the arithmetic is yours to do rather than ours to report. Ours is [documented here](/docs/history).
If a supplier can give you both, the advertised number is checkable. If they can give you neither, it is a number on a slide.

### What we do about it

Every round we settle is pinned to a certified release, and that release's RTP is the binding figure. It is on the game page, in the catalogue API, and on the round itself.
Operators on a paid plan can set their own RTP within a published band on games that support it, and the value used is the one recorded against the round — so changing it changes future rounds and leaves past ones auditable.

## Idempotency in a betting API, and why the key is yours

Source: https://casinoapipro.com/blog/idempotency-in-betting-apis
Published: 2026-09-21
Summary: The safest design gives the caller the idempotency key rather than generating one. If you mint the transaction id, a retry after a timeout is unambiguous — and a timeout is the one failure every integration eventually meets.

### The failure everybody meets

You send a bet. The connection times out. You do not know whether it landed.
Without idempotency you have two bad options: retry and risk charging twice, or do not retry and risk a player who lost money on a round that never opened. Both happen, and both generate the kind of support ticket that takes a week.

### Who mints the key

Some APIs generate an id and return it. That is fine until the response is the thing that goes missing, at which point you cannot retry safely because you never learned the id.
So the transaction id is yours. You generate it, you send it, and it is the key the movement is recorded under on both sides. A retry is the same request byte for byte, and it is safe by construction rather than by convention.

### What a correct replay does

A replayed transaction returns the same result as the first one and moves no money. Not an error, not a duplicate record, not a 409 the caller has to interpret — the same answer.
That property has to hold in both directions. We hold it for [calls you make to us](/docs/idempotency), and we require it of your wallet for the calls we make to you, because a chain is only as idempotent as its least careful link.

### The three cases to test

- **Immediate replay.** Same id twice in a row, one movement.
- **Delayed replay.** Same id an hour later, after the round has settled. Still one movement.
- **Concurrent replay.** The same id twice at once, which is what an aggressive retry actually looks like. Still one movement — this is the one that catches implementations relying on a read-then-write instead of a unique constraint.
The third is the one most integrations fail, and it fails only under load, which is to say in production.

## Why we publish prices and hand out keys without a sales call

Source: https://casinoapipro.com/blog/self-serve-versus-sales-call
Published: 2026-09-21
Summary: Every aggregator in this market asks you to book a demo before seeing anything. We publish the prices, the limits and the documentation, and issue sandbox keys instantly — because an integrator can evaluate an API far better than a salesperson can describe it.

### The standard arrangement

Search for a casino game aggregator and every result offers the same thing: thousands of games from hundreds of studios, and a form. No prices, no limits, no documentation until someone has qualified you.
That is a choice, and it is usually defensible on their side: enterprise deals, revenue-share negotiated per account, integrations that genuinely need hand-holding.

### What it costs

It costs the buyer a fortnight. You cannot compare two suppliers without talking to both, and you cannot evaluate an API by talking about it — you evaluate it by calling it and seeing what comes back.
It costs the supplier the developers. The person who will actually integrate you is rarely the person on the call, and they form their opinion in the first hour of reading documentation. If there is no documentation to read, the opinion forms anyway.

### What we publish instead

- **Prices**, with the limits each plan carries, enforced in code rather than described on a slide.
- **[The full API reference](/docs)**, including the wallet contract we expect you to implement and every error code we can return.
- **Sandbox keys**, immediately, with play money and every game enabled.
- **The RTP of every game**, and a public verifier for any round we have settled.

### The honest caveat

Self-serve suits a smaller, own-built catalogue. We are not aggregating two hundred studios, and if what you need is fifteen thousand titles then one of the aggregators is the right answer and we would say so.
What self-serve buys you is the ability to find that out this afternoon rather than after two calls.

---

# Games

## Goal Jet

Source: https://casinoapipro.com/games/goal-jet
Category: Crash. RTP: 97.00%. Volatility: high. Stakes: 0.50 to 50000.00.

A shared flight every player watches at once. Cash out before it stops, or lose the stake.

## Mines

Source: https://casinoapipro.com/games/mines
Category: Instant. RTP: 97.00%. Volatility: variable. Stakes: 0.10 to 50000.00.

A 5x5 board. Open safe tiles to climb the multiplier; one bomb ends the round.

## Spin da' Bottle

Source: https://casinoapipro.com/games/spin-bottle
Category: Instant. RTP: 95.56%. Volatility: low. Stakes: 0.50 to 50000.00.

Call up or down, spin, and take 2x if the neck lands on your half.

## Magic Ball

Source: https://casinoapipro.com/games/magic-ball
Category: Instant. RTP: 96.67%. Volatility: medium. Stakes: 0.20 to 10000.00.

Three cups, one ball. Cover a cup and take 2.9x if the ball is under it.

## Dice

Source: https://casinoapipro.com/games/dice
Category: Instant. RTP: 97.00%. Volatility: player-chosen. Stakes: 0.10 to 50000.00.

Pick a target and roll under it. Every target pays the same expected return, so the choice is volatility rather than value.

## Lucky Wheel

Source: https://casinoapipro.com/games/lucky-wheel
Category: Instant. RTP: 97.00%. Volatility: high. Stakes: 0.20 to 50000.00.

Sixteen prizes, one spin, from 0.2x back to 150x. The faces are equal and the odds are not, so every chance is published on the paytable.

## Under Over 7

Source: https://casinoapipro.com/games/under-over-7
Category: Instant. RTP: 96.67%. Volatility: player-chosen. Stakes: 0.20 to 50000.00.

Two dice, one call: under seven, exactly seven, or over. Every option returns the same, so the seven is rarer and larger rather than a worse bet.

## Nova Drop

Source: https://casinoapipro.com/games/nova-drop
Category: Instant. RTP: 97.01%. Volatility: high. Stakes: 0.20 to 50000.00.

A ball falls through eight rows of pegs into one of nine slots. The odds are not a setting — they are Pascal’s triangle, and the corners pay 29x because only one path in 256 reaches them.