Casino Api Pro

Reference

Team and account

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

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

iAn 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/invitesdashboard

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

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}dashboard
PATCH/v1/businessapi key

Body

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

Your account’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’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/brandsdashboard
GET/v1/brandsapi key

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}dashboard
PATCH/v1/brands/{brandId}api key

Body

name
stringoptional
What players see. The slug never changes — it is in launch URLs.
domain
string | nulloptional
The domain this brand launches under. Null clears it.
status
enumoptional
ACTIVE or SUSPENDED. Reactivating is checked against your plan's brand limit.
theme
objectoptional
Launcher colours, applied by the game shell. Free-form.

Support tickets

POST/v1/dashboard/ticketsdashboard
POST/v1/ticketsapi key

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.

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 and it takes us straight to the request in the log.

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

Notifications

GET/v1/dashboard/notificationsdashboard
GET/v1/notificationsapi key

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}/rtpdashboard
POST/v1/catalogue/{gameId}/rtpapi key

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 every game except Twin Wheels, Prize Drum, Gem Rush, Chilli Sevens, Big Top Coins and Prism Sevens. Their returns are fixed: the payouts are printed on what the player sees and the odds are what the player sees, so no setting changes the return without changing the game. The console says so, and supports_custom_rtp is false for all six.
  • 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.