Test mode

A qk_test_ key is a first-class environment, not a demo mode: same endpoints and schemas, zero credit charges, and a workspace daily quota that prevents abuse.

What test keys are for

Building the integration. Write and debug your whole flow - parsing, error handling, retries, webhook handling - without spending a credit.
CI. Test calls return deterministic fixtures, so assertions stay green.
Demos and experiments. Portal Quickstart creates a test key and runs a free first call; use a test key from your own client for subsequent experiments.

A data call in test mode

curl -X POST https://api.qannasapi.com/v1/data/companies/enrich \
  -H "Authorization: Bearer qk_test_replace_me" \
  -H "Content-Type: application/json" \
  -d '{"query": "acme.com"}'

# HTTP 200 - X-Credits-Charged: 0. Test calls return deterministic fixture data.

The contract

Test-key calls never charge credits and return deterministic fixture data.
Only documented data actions are available in test mode.
X-Credits-Charged: 0 on every test call; the credit headers are still present so your header-parsing code runs end to end.
The error model is identical, and the workspace daily quota returns a standard 429 when exhausted.

Don't benchmark on test mode. Fixture-backed actions say nothing about live hit rates or latency. For public quality numbers use GET /v1/public/hit-rates, and for a live trial run a handful of real calls on a qk_live_ key: misses are free, so a live evaluation only ever costs you for data you actually got.

Going live

Create a live key under Settings → API keys and swap the token — the base URL and every request stay byte-identical. Keep the test key around for CI; the two never interfere.