Sandbox. Evaluate before paying.

Sandbox keys hit a fixture dataset that’s isolated from production. No quota burn, no audit log spam, no risk of billing yourself accidentally. Wire your whole integration against the sandbox first; flip to live by swapping one key.

Minting a sandbox key

Same endpoint as a live key, with ?mode=sandbox:

POST /v1/account/keys?mode=sandbox
Authorization: Bearer <your-session-key>

# → 201 Created
{
  "data": {
    "id": "k_01HMXYZ...",
    "raw": "esp_test_abcd1234abcd1234abcd12",
    "prefix": "esp_test_",
    "mode": "sandbox",
    "created_at": "2026-05-16T...",
    "name": null
  }
}

The raw value is the only time we ever show the full key. Save it now — we hash it on store. Sandbox keys are not gated by subscription: any signed-in user can mint one regardless of paid status. Cited in ADR-0022 as the chicken-and-egg fix for the “I need to pay to evaluate” friction.

Calling with a sandbox key

Identical to a live call. The middleware sees the esp_test_ prefix and routes to the fixture schema:

$ curl https://api.stadar.net/v1/matches?status=live     -H "Authorization: Bearer esp_test_abcd1234abcd1234abcd12"

{
  "data": [...],
  "meta": {
    "sandbox": true,
    "sources": [...],
    "next_cursor": null,
    "limit": 100
  }
}

Note meta.sandbox: true on every response. We are not pretending these are real matches. Use it in your tests as a guard against accidentally pointing your test suite at production data.

What’s in the fixture set

Curated snapshot of ~50 matches across all 6 v1 games, refreshed monthly:

• LoL — ~10 matches, mix of LCS/LEC/LPL/MSI
• CS2 — ~10 matches, mix of ESL/BLAST/PGL events
• Dota 2 — ~8 matches, recent DPC tournaments
• Valorant — ~8 matches, VCT international
• Rocket League — ~7 matches, RLCS events
• R6 Siege — ~7 matches, BLAST R6 events

Every state is represented: scheduled (future), live (in progress), completed (with full score). Tournaments, brackets, rosters, and the entity hierarchy (ADR-0014) are all populated. Match stats (Hobbyist+ capability) and brackets (Hobbyist+) are included so you can evaluate the paid features.

The fixture set is loaded into a separate esports_sandbox MySQL schema at API startup, not driven by the scraper. We refresh the seed monthly — typically the first week — but a stale fixture set is the worst kind of “demo data”, so we audit the refresh cadence quarterly.

What’s NOT in the sandbox

• Outbound webhooks. Sandbox keys can’t subscribe; we don’t want flooding your dev endpoints with fixture events.
• Real-time events. Same reason. The “live” matches in fixtures are static — the API returns the same payload each time.
• Rate-limit production values. Sandbox enforces a separate sandbox_usage_daily counter capped at 10k/day per key. Generous for evaluation; not representative of your production tier’s limit.
• ClickHouse api_request_log entries. Sandbox calls are excluded from the telemetry table to keep dashboards clean.

Switching to production

When you’re ready to bill real customers:

1. Mint a live key: POST /v1/account/keys (no ?mode=sandbox).
2. Swap the env var in your deployment. Same Authorization header shape; same endpoint paths; same response envelope.
3. The first live call costs a quota credit. The first sandbox call doesn’t. That’s how you verify the switch worked — watch X-RateLimit-Daily-Remaining drop by 1 on the live call.

Everything you wrote against the sandbox keeps working. We deliberately keep the fixture shape identical to production so the swap is one env-var change.