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.

Exchanging for a token#

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" }'

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

Using the token#

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.

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

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.