API keys

Create and operate project-bound API credentials with explicit environment and authority.

API keys authenticate requests to api.quiver.ai. Each key belongs permanently to one project and has an environment, an owning principal, and explicit authority over capabilities and models.

Environments

• Production keys send real model requests and create billable usage.
• Test keys use the production API base URL, but only supported sandbox endpoints return mock responses without model calls or charges. The Responses API is unavailable to Test keys and returns 404.

The environment cannot be changed after creation. Use separate keys when an integration needs both Test and Production traffic.

Ownership and authority

A key can be owned by a person or a service account. Prefer a service account for production integrations so the credential is not coupled to a member’s lifecycle.

Authority controls which API capabilities and models a key may use. Grant only what the integration needs. Authority and project binding cannot be edited after creation; create a replacement key when either must change.

Secret lifecycle

The full secret is available only when the key is created or rotated. Store it in a secrets manager, never in source control or client-side code.

Rotation replaces the secret while preserving project attribution and authority. You can choose a grace period during which the outgoing secret and new secret overlap: deploy the new secret before that period ends. The no-overlap option retires the outgoing secret immediately. In either case, the outgoing secret can continue authenticating for about a minute after its retirement time while invalidation finishes.

Revoke a key when it should no longer authenticate and no overlap is needed. Clients using it can continue authenticating for about a minute while invalidation finishes.

Continue with the Quickstart, or use the API Reference for authentication and endpoint details.