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. There is no separate sandbox host — test keys call the same https://api.quiver.ai endpoints as production; only the key you send decides whether the request is stubbed or real.

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 hammering the sandbox can’t throttle your production traffic.

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 sandbox does not have a mock scenario for /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"
}

This is intentionally the same 404 you’d get for a route that doesn’t exist, not a distinct “not available in test mode” error — the route is real and publicly documented, and a test key caller may already be using it against production. What’s absent is a sandbox stub for it, which is a property of the test key, not of the route itself. Use a production key against /v1/responses, or avoid calling it from sandbox integration tests.

Next steps

  • Create a test key from API Keys — the environment choice is made once, at creation, and can’t be changed later.
  • See the Quickstart for the request/response shapes the sandbox mirrors.
  • See pricing and plans — sandbox usage is excluded from spend entirely.

Was this page helpful?