# 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’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/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 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](/docs/provably-fair).