Get started
Test mode & live mode
What differs between sandbox and production, and the checklist for going live.
Every account starts in test mode. Test and live are separate credentials, separate data and separate money — there is no flag that turns one into the other by accident.
What differs
Credentialsck_test_ / ck_live_ | Prefixed so you can tell at a glance which environment a log line came from. |
Moneyplay / real | Test credentials cannot move real money under any circumstances. |
Walletseparate records | Each environment has its own wallet integration. Test mode can use the built-in play-money wallet or your staging one; live uses whatever you configured for live, and never falls back. |
Gamessame | Identical engine, identical mathematics, identical versions. Only the money differs. |
Dataseparate | Players, sessions, rounds, transactions, free bets and your API request log all belong to one environment. A test player is not a live player even under the same player_id, and nothing you see in one mode is ever from the other. |
Rate limitsame | Your plan’s requests-per-minute budget, identical in both. Test traffic is not given a looser allowance, so a load test in sandbox measures the limit you will actually meet. |
Playerscapped in sandbox | Sandbox allows 100 distinct players on the free plan; live is uncapped. Sandbox is for building and testing, and a hundred is far more than any integration needs \u2014 the limit exists so that a free account cannot quietly be run as a real casino. Paid plans have no sandbox cap, because live is already available to them. If you are genuinely load-testing and need more, ask and we will raise it for your account. |
iNothing crosses between them
✓The engine is the same code
One host, two kinds of key
There is no separate sandbox hostname. Every request in both environments goes to https://api.casinoapipro.com, and the key you exchange for a token is what puts you in one environment or the other. Nothing else in your integration changes between them — not the host, not a header, not a query parameter.
https://api.casinoapipro.com ck_test_… → sandbox
https://api.casinoapipro.com ck_live_… → liveThe token you get back carries the environment, and every route reads it from there. A live token cannot see sandbox data and a test token cannot move real money; there is no flag that turns one into the other.
·The health endpoint says nothing about your account
GET /health returns status, version and uptime_seconds — it is unauthenticated and tells you the platform is up, not what you are entitled to. Read your own state from the dashboard or the account endpoints instead.Going live
Issuing live credentials is self-service: you generate them in the dashboard the moment your plan is active. There is no approval queue and nothing to wait for on our side. What is worth doing first is proving the parts that are expensive to get wrong in production.
- Configure a live wallet integration. It is a separate record from your sandbox one. Until it exists, live money calls fail with
WALLET_NOT_CONFIGURED— deliberately, rather than falling back to the play-money wallet. This is the single commonest thing missed on the first live bet. - Prove your wallet is idempotent — replay the same
transactionIdand confirm one movement. - Prove your retry path — make the sandbox wallet time out and confirm you recover without double-debiting.
- Prove your reversal path — refund a bet and confirm you match on
referenceTransactionId, not on the reversal's own id. See the wallet contract. - Verify webhook signatures against the raw body, and confirm you deduplicate on event id.
- Swap the credentials.
!Keep the test credentials working