Run it from your own servers

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. Everything on this page is scoped to the account the key belongs to, so no endpoint takes an operator id.

Your catalogue#

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:

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.

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.

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#

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.

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.

Tournaments#

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.

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#

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}.

Chat moderation#

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.

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#

Is the shared flight in the air#

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.

Reconciling a round#

/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.

Currencies#

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.

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

Sandbox wallets#

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#

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.

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.

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.