Issuing an sk-dz key, choosing its custody, and making your first governed request through the keyed surface.

API Access

The API access track issues an sk-dz- key for your own apps, agents and CI: one endpoint, with budgets, guardrails and routing applied by DevZero.

This is the keyed product path. Unlike coding tools, a keyed request is governed, routed, optimized and metered, and it reaches only the product surfaces.

Issue a key

On the API Keys screen: create and manage the keys that carry traffic through the gateway. A key can be scoped to a person, a team or a service.

The plaintext token appears exactly once, on the response that creates it. Only its hash is stored, and every later read returns metadata only. If you lose it, issue a new one -- there is no route that will show it again.

A key's token is the prefix sk-dz- followed by 43 characters. Base62 is used deliberately, so the body carries none of base64's -, _ or =.

Choose its custody

Custody decides whose credential pays when this key forwards a request.

Custody	Behaviour
Managed	Forwards with the DevZero-provisioned credential for this team. If that credential cannot be resolved, the request is denied -- it never falls back to your own key.
BYOK	Forwards with your own provider credential. If that credential cannot be resolved, the request is denied -- it never falls back to DevZero's key.
Auto	Uses your own provider credential when the team has one, otherwise the DevZero-provisioned credential.

Only Managed and BYOK are selectable when issuing a key; Auto is what an unbound key resolves as.

The trade is explicit: an explicit binding fails closed, an unbound key falls back. A key that cannot resolve its explicitly bound credential is refused with a credential-unavailable error rather than quietly charged to the other party.

Keys issued before custody binding existed show as Legacy and resolve through the older ladder -- a pinned credential, else the team's default. Rotate such a key to bind it explicitly.

Set its limits

A key may carry a credit limit and a reset cadence of daily, weekly or monthly. Two rules are worth knowing:

A key owned by a person resolves as that person's identity policy and shares their counter bucket. Minting a key is never a budget bypass.
A service key -- one with no owner -- resolves against the team default and gets its own counter bucket keyed on the key id.

Broader rules -- budgets, rate and token ceilings, model and provider access -- belong to a guardrail, which is assigned to a team by default or to an individual issued key.

Make your first request

Point your existing SDK at the gateway and set the issued key as its API key. See Product surfaces for the routes, and remember the model vocabulary is author/slug:

curl https://<your-gateway-host>/v1/chat/completions \
  -H "Authorization: Bearer sk-dz-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-4-5",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Read X-Dz-Request-Id off the response to find the request in the dashboard, and X-Cache to see whether it was served from a cache.

The API access track verifies only on that key's own first use -- not on any traffic reaching the gateway, which is what the coding-tools track verifies on.

Attribute the traffic

A key identifies who is calling, but a single service key covers a lot of ground. Add the attribution headers so spend lands on the right project, environment and user:

-H "X-Dz-User: alice@example.com" \
-H "X-Dz-Project: checkout" \
-H "X-Dz-Env: production" \
-H "X-Dz-Session-Id: conv-8f21"

Sending X-Dz-Session-Id is the single cheapest thing you can do for the quality of your own measurements -- it is what makes the routing pin, cache-miss classification and holdout stickiness work across turns.

Revoking and disabling

Action	Effect
Disable	Reversible. The key stops authorizing and can be re-enabled.
Revoke	Not reversible. The key stops authorizing within the decision cache's freshness window and never comes back -- re-issue instead.

Revoked keys are hidden from key lists by default, and that default is deliberate: every binding surface -- guardrail assignment, routing profile, credential priority -- reads that list and must not offer a dead key.

Programmatic key management

The gateway also serves a small management API for key lifecycle, usage and model discovery, authenticated with an issued key and scoped per operation. See Management API.

Management keys are never enumerable through that external interface -- it lists runtime keys only.

API Access

On this page