Test vs live mode

Every API key is bound to a mode by its prefix: bqr_test_… or bqr_live_…. The two modes are completely isolated — a test key can never read or modify live data, and vice-versa. Test data is never billed and never appears in the operator app or manager reports.

The same code, both modes

Write your integration once. Swap the key to move between modes:

# Development
export BRIEFQR_KEY="bqr_test_..."

# Production
export BRIEFQR_KEY="bqr_live_..."

Objects created in test mode carry "livemode": false; live objects carry "livemode": true.

Cross-mode references are rejected

You cannot point a test session at a live device (or vice-versa). Mixing modes returns 422 validation_error with code: cross_mode_reference.

Live writes require a subscription

Reads and all test-mode writes always work. Live-mode writes require an active (or trialing) subscription; without one they return 403 insufficient_scope (code: subscription_required). This lets you build and demo entirely in test mode before subscribing.

Resetting the test namespace

Wipe every test operator, device, location, and session in one call with a full test key:

curl -X POST https://api.briefqr.com/v1/test-data/reset 
  -H "Authorization: Bearer bqr_test_..."

{ "object": "test_data_reset", "livemode": false,
  "deleted": { "operators": 12, "devices": 3, "locations": 2 } }

API keys are preserved. Reset only accepts a test key — calling it with a live key returns 403 (code: test_key_required).