--- title: "Sandbox and test keys" description: "How QuiverAI's test-mode keys work: no model dispatch, no cost, deterministic output, and the markers that identify it." icon: "flask-conical" --- 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: ```json { "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: ```http 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 `` element: ```xml ... ``` 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: ```json { "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](https://platform.quiver.ai/api-keys) — the environment choice is made once, at creation, and cannot be changed later. - Use [Text to SVG](/developers/models/text-to-svg) or [Image to SVG](/developers/models/image-to-svg) for native request examples. The [Quickstart](/developers/quickstart) uses the Production-only Responses API. - See [pricing and plans](/developers/pricing) — sandbox usage is excluded from spend entirely.