Skip to content
Esc
↑↓navigate↵open⌘Jpreview
On this page

Sandbox and test keys

How QuiverAI's test-mode keys work: no model dispatch, no cost, deterministic output, and the markers that identify it.

Every QuiverAI API key is created for one environment, chosen when the key is created and fixed for the key’s life: production (sk_live_...) or test (sk_test_...). This page covers the test environment — the sandbox.

What a test key does

A verified test key never reaches a model. api.quiver.ai routes the request to an in-process mock instead of dispatching inference, and returns a response built from the exact same published schema a production call would return for supported sandbox endpoints. There is no separate sandbox host: use https://api.quiver.ai. Not every Production endpoint has a sandbox fixture.

Because no inference happens:

  • Nothing is billed. Sandbox requests carry no credit cost.
  • The response is deterministic. The same request body from the same key produces byte-identical output every time, including across process restarts — useful for asserting on a response in your own test suite instead of matching loosely.
  • Ordinary rate limits still apply. A test key is not exempt from rate limiting — request flooding is still an abuse vector even against a mock — but sandbox capacity is resolved from its own budget, independent of your organization’s paid tier. Evaluating the API does not require buying capacity first, and sandbox requests do not consume Production capacity buckets.

The sandbox serves the same models production would

Model visibility and admission mirror production for your organization. GET /v1/models on a test key lists exactly what it would list for a live key on the same organization — same catalog, same preview rollouts, Arrow 2 included — and every listed model is callable on the SVG routes the sandbox serves. A model your organization is not entitled to returns 404 model_not_found for both keys, so a sandbox integration test proves your production model access rather than a broader sandbox catalog.

Token-priced responses carry the same usage block production returns:

{
  "usage": { "input_tokens": 120, "output_tokens": 220, "total_tokens": 340 }
}

Those counts are mock values, fixed by the same determinism as the rest of the response. Nothing is billed and nothing is counted against your token capacity — parse the block and assert on its shape, not on what it would have cost.

Identifying a sandbox response

Every response served to a test key carries a response header:

x-quiver-environment: test

Check for this header in any code path that treats a response as billable or as real output — for example before caching a generation, queuing it for review, or writing it to a datastore your production pipeline also reads from.

The SVG marker

Every SVG a sandbox response returns carries a marker attribute on its root <svg> element:

<svg data-quiver-sandbox="true" viewBox="0 0 24 24">...</svg>

This is deliberate and unmistakable: a mock SVG should never be reviewable, shippable, or cacheable as a real generation. If your pipeline stores or renders generated SVGs, check for this attribute before treating one as production output — the same rule as the response header, expressed in the artifact itself so it survives being copied out of the response body.

Font exports return placeholder bytes

A sandbox call to /v1/fonts/exports returns a response with the same shape as production — font_base64, font_name, format, glyph_count, and so on — but font_base64 decodes to a short placeholder string, not a renderable TTF. Do not attempt to load or render a sandbox font export as a font file; treat it the same way you’d treat any other sandbox artifact — good for proving your wiring and your response parsing, not for visual output.

Triggering specific outcomes

The sandbox recognizes a small set of markers you can put in specific request fields to deliberately exercise error and edge-case handling before production exercises it for you:

Marker Where Effect
[mock:partial-font] in the prompt of a font generation request returns a font with only a partial glyph set, as if generation had stopped early
[mock:partial-icons] in the prompt of an icon generation request drops the last subject from the response, simulating a partially completed batch
[mock:failed-icon] in a subject’s text field of an icon generation request that one subject comes back with status: "failed" while the rest of the batch succeeds
[mock:slow-stream] in the prompt of a streaming request slows the stream down, useful for testing client-side timeout handling

These markers are inert in production — sending one to a production key does not do anything special, since production never inspects the prompt for a sandbox marker.

/v1/responses is not available in the sandbox

The public sandbox does not serve /v1/responses. A verified test key calling that route gets a 404, not a stub:

{
  "status": 404,
  "code": "invalid_request",
  "message": "Not found",
  "request_id": "550e8400-e29b-41d4-a716-446655440000"
}

Use a Production key for /v1/responses. Use supported native endpoints, such as /v1/svgs/generations and /v1/svgs/vectorizations, for sandbox integration tests.

Next steps

  • Create a test key from API Keys — the environment choice is made once, at creation, and cannot be changed later.
  • Use Text to SVG or Image to SVG for native request examples. The Quickstart uses the Production-only Responses API.
  • See pricing and plans — sandbox usage is excluded from spend entirely.

Was this page helpful?