How to test a casino game API for free

Why test before you integrate

Launching a game is usually the easy part of a casino game API integration. A single request returns an iframe URL and the game loads. The hard part is the wallet: every spin, win and correction arrives as a callback to your server, and your server is responsible for keeping the player balance correct.

Wallet callbacks are where integrations break. A retried bet callback processed twice becomes a double debit. A rollback that your server ignores leaves a player charged for a round that never completed. A callback endpoint that does not check signatures will accept requests from anyone who finds the URL. None of these problems show up when you only launch a game and look at it.

A sandbox lets you find these problems with a simulated balance instead of real funds. You can send the same requests you will send in production, receive the same callback types and fix your wallet logic before any player or prepaid balance is involved.

Step 1: Get a free sandbox key

Sign up for free sandbox access on casino-games-aggregation.com/register. There is no top-up and no crypto payment for the sandbox. You receive a test API key and the sandbox endpoint to use with it; casino201 does not publish a sandbox hostname, so use the endpoint sent with your key.

Store the key and endpoint in server-side configuration, for example as CASINO201_API_KEY and CASINO201_ENDPOINT environment variables. Never put the key in browser code, a mobile app bundle or a public repository. The /sandbox page summarises what the sandbox includes.

Step 2: Start a game session

Create a game session from your server with POST /api/v1/game-sessions/start, using a Bearer API key. The request names the game, your player, the session currency, country, IP address, locale, device and the return_url the player goes back to. These are the same samples used in the docs quickstart; replace the example values with your own and a demo game ID available to your sandbox.

The response contains data.session_id, data.session_token, data.expires_at and data.iframe_url. Load iframe_url for the player to open the demo game. From this point, the game will call your wallet endpoint.

curl -X POST "$CASINO201_ENDPOINT/api/v1/game-sessions/start" \
  -H "Authorization: Bearer $CASINO201_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "game_id": 123,
    "player_id": "player_456",
    "currency": "EUR",
    "country_code": "US",
    "ip_address": "203.0.113.24",
    "locale": "en",
    "device": "mobile",
    "return_url": "https://yourcasino.com/lobby"
  }'

const response = await fetch(`${process.env.CASINO201_ENDPOINT}/api/v1/game-sessions/start`, {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.CASINO201_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    game_id: 123,
    player_id: 'player_456',
    currency: 'EUR',
    country_code: 'US',
    ip_address: request.ip,
    locale: 'en',
    device: 'mobile',
    return_url: 'https://yourcasino.com/lobby',
  }),
});

const { data: gameSession } = await response.json();
// Load gameSession.iframe_url for the player

$payload = json_encode([
    'game_id'      => 123,
    'player_id'    => 'player_456',
    'currency'     => 'EUR',
    'country_code' => 'US',
    'ip_address'   => $_SERVER['REMOTE_ADDR'],
    'locale'       => 'en',
    'device'       => 'mobile',
    'return_url'   => 'https://yourcasino.com/lobby',
]);

$curl = curl_init(getenv('CASINO201_ENDPOINT') . '/api/v1/game-sessions/start');
curl_setopt_array($curl, [
    CURLOPT_POST           => true,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POSTFIELDS     => $payload,
    CURLOPT_HTTPHEADER     => [
        'Authorization: Bearer ' . getenv('CASINO201_API_KEY'),
        'Content-Type: application/json',
    ],
]);

$gameSession = json_decode(curl_exec($curl), true)['data'];
// Load $gameSession['iframe_url'] for the player

Step 3: Handle wallet callbacks

Your wallet endpoint receives authenticate, balance, bet, win, rollback, reward callbacks. Authenticate confirms the player and session, balance returns the current balance, bet debits a stake, win credits a payout, rollback reverses a previous transaction and reward credits a bonus amount.

Design every handler to be idempotent. Networks time out and callbacks can be retried, so the same transaction may reach you more than once. Record each transaction you process and, when a repeated callback arrives for a transaction you have already applied, return the original result instead of debiting or crediting again. Apply this to rollbacks too: a rollback for a transaction you never recorded, or one already reversed, must not change the balance a second time.

Exact transaction ID fields are in the field reference included with your sandbox key. Use those fields as your idempotency key rather than guessing from the payload.

Step 4: Verify X-Signature

Each callback carries an X-Signature header: HMAC-SHA256 of the raw request body, computed with your webhook secret. Verify it before you parse or process anything. Keep the raw body bytes exactly as received, because re-serializing parsed JSON can change the bytes that were signed.

Compute the expected digest, compare it to the received signature in constant time and reject the request if they do not match. The snippets below are the same ones used in the wallet callbacks docs. They take a decodeSignature function because the signature encoding is supplied with your sandbox key; do not assume hex or base64.

import { createHmac, timingSafeEqual } from 'node:crypto';

// Keep the exact raw body bytes; do not re-serialize parsed JSON.
export function verifyCallback(rawBody, signature, webhookSecret, decodeSignature) {
  if (!signature || !webhookSecret) return false;
  try {
    // Decode X-Signature using the encoding supplied with your key.
    const received = decodeSignature(signature);
    if (!Buffer.isBuffer(received)) return false;
    const expected = createHmac('sha256', webhookSecret).update(rawBody).digest();
    return received.length === expected.length && timingSafeEqual(received, expected);
  } catch {
    return false;
  }
}

// Pass the raw body and X-Signature before parsing or processing.
// Full field reference is included with your sandbox key.

<?php
function verifyCallback(string $rawBody, string $signature,
    string $webhookSecret, callable $decodeSignature): bool {
    if ($signature === '' || $webhookSecret === '') return false;
    try {
        // Decode X-Signature using the encoding supplied with your key.
        $received = $decodeSignature($signature);
        if (!is_string($received)) return false;
        $expected = hash_hmac('sha256', $rawBody, $webhookSecret, true);
        return hash_equals($expected, $received);
    } catch (Throwable $error) {
        return false;
    }
}

$rawBody = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_SIGNATURE'] ?? '';
// Verify before parsing or processing. Keep the secret server-side.
// Full field reference is included with your sandbox key.

Step 5: Run the hosted test suite, then go live

Sandbox access includes a hosted test suite. Run it against your wallet endpoint to exercise the callback flow, including repeated callbacks and rollbacks, and fix anything it reports before you switch environments.

Going live uses the same integration with a production key. Live accounts, top-ups and production API keys are created on casino-games-aggregation.com/register. The differences between environments are:

Pre-launch checklist

• API key and webhook secret are stored server-side only, never in browser code or public repositories.
• All API requests are made from your server with the Bearer API key.
• The IP/CIDR allowlist is configured for the servers that make API requests.
• X-Signature is verified against the raw request body before any processing.
• Signatures are compared in constant time and failed checks are rejected.
• Repeated callbacks for the same transaction return the original result without a second debit or credit.
• Rollbacks reverse the original transaction once and are safe to receive more than once.
• Each session is started with the correct currency for the player.
• return_url points to the page the player should return to in your lobby.
• The hosted test suite passes before you switch to your production key.

Next steps