Virtual keys

Virtual keys are what your applications authenticate with — never a raw OpenAI, Anthropic, or Gemini key.

Why not just use provider keys?

A raw provider key is all-or-nothing: whoever has it can call any model, at any rate, with no spend ceiling, and no record of which service made which call. That's fine for a single script. It falls apart the moment you have more than one project, environment, or team touching LLMs.

How virtual keys work

1. An admin creates a project — a logical owner for a slice of usage (a service, an environment, a team).
2. The project is granted access to specific models, across one or more providers.
3. A virtual key is issued for that project, optionally behind an approval workflow before it's active.
4. Applications use that virtual key as the Authorization: Bearer token against /api/data/v1/chat/completions.

The gateway resolves the virtual key to its project on every request, and enforces that project's model access, rate limits, and budget — before the request ever reaches a provider.

Rotation and revocation

Because a virtual key is just a pointer to a project's permissions, revoking access doesn't mean rotating a provider key everywhere it's used. Revoke or rotate the virtual key from the dashboard, and every caller using it is cut off immediately — the underlying provider credential never has to move.

Approval workflows

New virtual keys can be configured to require admin approval before they're usable — useful when you want a second set of eyes before a new service gets production access to paid models.