API keys

Create and operate project keys for inference and organization admin keys for organization reads.

API keys authenticate requests to api.quiver.ai. Project keys belong permanently to one project and have an environment, an owning principal, and explicit authority over capabilities and models. Organization admin keys authorize organization-level reads.

Credential scope

Use a project key for inference and model-catalog requests. A project key’s permissions, including *, never grant organization billing access.

Use an organization admin key for organization-level reads. Only an organization Owner or Admin can create or manage these keys. Admin keys are owned by the creating membership, have no project binding or Test/Production environment, and cannot run inference or access model routes. Their permissions come from a separate organization taxonomy: billing_read, or * for all current and future organization permissions. They have no model grants.

Service accounts remain project-scoped and own project keys only. To change an Admin member to a Developer or Viewer, revoke or reassign the keys that prevent that role change first.

Admin key permissions cannot be edited. Create a replacement admin key and revoke the old one when authority must change. Admin keys support creation and revocation; the rotation guidance below applies to project keys.

Environments

• Production keys send real model requests and create billable usage.
• Test keys use the production API base URL, and every endpoint returns a mock response without model calls or charges.

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.

Migrate to Arrow 2

See Migrate to Arrow 2 for the retiring model IDs and their replacement. We recommend creating a new project API key for Arrow 2. A new key is required if your existing key does not allow Arrow 2 or the required operation; rotating a key’s secret cannot grant new authority.

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.