API keys

Creating, listing, and revoking keys — and what Atlas can and cannot tell you about one afterwards.

The format

An Atlas inference key is 56 characters:

atl_live_7k2m9qr4vx8thn3p_wj6b2yd0fs1gzr4mcqvn8ka3hpx91t
└───┬───┘└──────┬───────┘ └────────────┬──────────────┘
  scope     public id              secret + checksum

atl_live_ — the scan prefix. It makes a leaked key recognizable in a repository or a log by automated secret scanners.
The public id — 16 characters. This is the lookup handle, and it is not secret: it is what the console shows you after creation.
The secret and a checksum — the part that authenticates, plus four characters that let a mistyped key be rejected without a database lookup.

The public id and the secret are independent draws. Someone who learns your key's prefix from a screenshot has narrowed the search space by exactly zero bits.

There is a second scope, atl_read_, for read-only access to the usage API. See Read-scoped keys below.

Keys are created in the console, by any member or owner. Give the key a label saying what it is for — up to 80 characters. Labels are how you tell keys apart afterwards, because you will never see the key material again.

The creation response is the only one that carries the key:

{
  "id": "8f2c1d5e-...",
  "label": "checkout-service prod",
  "prefix": "atl_live_7k2m9qr4vx8thn3p",
  "created_by_user_id": "...",
  "created_at": "2026-09-09T10:14:02.000Z",
  "last_used_at": null,
  "revoked_at": null,
  "key": "atl_live_7k2m9qr4vx8thn3p_wj6b2yd0fs1gzr4mcqvn8ka3hpx91t",
  "note": "Store this key now. It is shown once and cannot be retrieved again."
}

The key is shown once. Atlas stores only an irreversible hash of the secret. There is no recovery path, no support escalation, and no Atlas operator who can read it back — the operator-facing view of a key is byte-identical to yours. If you lose it, revoke it and create another.

Listing keys

Every member sees every key in the organization, as its non-secret projection:

Field
`id`	The key's row id, used to revoke it. Never appears on the wire to the gateway.
`label`	What you named it.
`prefix`	`atl_live_` plus the public id. Match this against a key you hold.
`created_by_user_id`	Who created it.
`created_at`
`last_used_at`	When it last authenticated a request, or `null`.
`revoked_at`	When it was revoked, or `null`.

Nothing in this projection can be turned back into key material.

The whole organization's keys are visible to every member, not just your own. Hiding them would buy nothing — a member can already tell a key exists when an owner revokes it — and would cost an owner the view they need.

Revoking a key

Actor	May revoke
Member	Keys they created.
Owner	Any key in the organization.

A member attempting to revoke another member's key is refused. A key id that does not exist — or belongs to another organization — is reported as not found rather than as forbidden, so the response cannot be used to probe which ids are real.

Revocation is immediate. There is no cache to expire and no propagation delay: the gateway verifies a key with a single indexed read of the row the revocation just wrote, so the very next request presenting that key is rejected with 401 authentication_error.

Revoking an already-revoked key is not an error — it is reported as such rather than failing, so a retried revocation is safe.

Read-scoped keys

Keys beginning atl_read_ authenticate the usage surface only — GET /v1/usage and GET /v1/usage/export — and nothing else. They cannot make inference requests.

They exist so you can automate usage reads and reconciliation without handing a scheduled job a key that can spend money.

Read-scoped keys are currently provisioned by Atlas on request. Creating one is not yet self-serve in the console; ask your Atlas contact. Inference keys are self-serve as described above.

The scope is enforced against the stored scope, never the prefix presented: a caller who edits atl_live_ to atl_read_ on a key they hold gets a 401, not a scope upgrade.

Handling keys well

One key per deployed service, labelled with the service name. The whole value of last_used_at and of per-key usage breakdowns depends on keys not being shared across systems. See Usage and cost.
Rotate by overlap: create the new key, deploy it, confirm the old key's last_used_at has stopped advancing, then revoke. Revocation is instant, so revoking first means an outage.
Never put a key in a label. The label is echoed back in listings; the refusal for an invalid label deliberately does not quote what you sent, for exactly this reason.
Treat the prefix as the identifier in your own logs. It is non-secret by construction and it is what lets you match a log line to a key in the console.