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.

Base URL#

All endpoints are served over HTTPS at:

https://api.casinoapipro.com/v1

How money is represented#

Amounts are decimal strings, never JSON numbers."10.50" is valid; 10.5 is rejected with aVALIDATION_ERROR. This is deliberate: IEEE-754 doubles cannot represent0.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.

{
  "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:

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

{
  "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.

{
  "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.

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

Where to go next#

• Quickstart — first session in about ten minutes.
• Authentication — credentials, tokens, scopes.
• Wallet integration — the five calls we make to you.
• OpenAPI explorer ↗ — try every endpoint in the browser.