estøkad

API keys

Per-workspace bearer tokens that authenticate REST and GraphQL requests. Issued from /settings/api-keys in the Studio; plaintext is shown once at creation and the server only stores a SHA-256 hash.

Issuing a key

  1. Open /settings/api-keys.
  2. Pick a name (e.g. "Waretto production"), a space (defaults to your default space), and a scope.
  3. Click Issue key. The plaintext appears in a one-time reveal box. Copy it.
  4. Use as Authorization: Bearer estk_… in your requests.

Keys never leave the issuance flow in plaintext after that. Lose it, and you rotate.

Scopes

| Scope | Reads published | Reads drafts | Writes content | Manages | |---|---|---|---|---| | read | yes | — | — | — | | read_draft | yes | yes | — | — | | write | yes | yes | yes | — | | management | yes | yes | yes | yes |

Pick the narrowest scope that does the job. A static site fetching published entries needs read, not read_draft. A CMS-as-API integration writing webhooks needs write, not management.

Per-space scoping

Each key is bound to one space. read and read_draft keys can fetch only entries in that space. management keys can push schema only into that space. This bounds blast radius — a leaked production key for the marketing space cannot touch the editorial space.

The default space is the one that ships with every workspace. Multi-space customers create additional spaces; each needs its own keys.

Last-used and rotation

Every successful request stamps lastUsedAt on the key row. The Studio's API keys list shows it as "5m ago" / "2d ago" / "never," which makes spotting unused keys trivial.

Rotate aggressively:

  • After a contractor leaves the project
  • After any leak suspicion (a pasted credential in a shared doc, a public GitHub commit)
  • On a 90-day cadence as a baseline hygiene rule

Rotation is two-step: issue a new key, deploy it, revoke the old one. There is no overlap window in the API; the new and old keys both work simultaneously until the old one is revoked.

Revoking

Click Revoke on the row. Subsequent requests with the revoked key get 401. The row stays in the list (greyed out) for audit purposes — knowing a key existed and when it was active matters for incident response.

Audit

Every key issuance, last-used update, and revocation is logged into the workspace's audit chain. Filter by actor_type='api_key' to see API-driven activity.