Authentication
All requests must include an Authorization header with a Bearer token.
Authorization: Bearer zmk_live_<prefix>_<secret>Key format
Keys look like zmk_live_AB12CD34_<32-char-secret>. The first part (zmk_live_AB12CD34) is the prefix — it's safe to log and identifies the key. The second part is the secret and must never be logged or committed to source control.
Tenant scoping
Every key is scoped to one creator (tenant). The API enforces that you can only read your own data — passing an id that belongs to another tenant returns 404 not_found (not 403, to avoid enumeration).
Errors
401 unauthorized— missing, invalid, disabled, revoked, or expired key (the message body distinguishes them)403 plan_inactive— your subscription is past due or cancelled403 plan_does_not_include_api— your plan doesn't include API access; upgrade in Settings403 scope_missing— the key doesn't have the required scope for this endpoint
Managing keys
Go to Settings → Integrations → API. You can keep up to 10 keys per account (active or disabled, excluding revoked).
Each key has one of three states:
- Active — accepted by the API.
- Disabled — reversible pause. The key is rejected with
401 unauthorized(API key is disabled.) until you re-enable it. Useful for temporarily turning off an integration without losing the key. - Revoked — permanent. The key is rejected with
401 unauthorized(API key has been revoked.) and cannot be restored. Generate a new key to replace it.
You can rename a key at any time. For identification, the dashboard shows the prefix plus the last 4 characters of the secret (zmk_live_xxxxxxxx_••••••••XXXX); the full secret is shown only once at creation. Keys generated before this feature shipped display …(hidden) instead — revoke and regenerate them to get the partial reveal.
Security notes
- Store keys in environment variables, not source control.
- Rotate keys if you suspect compromise.
- The
X-Request-Idresponse header is included on every response — include it when reporting issues to support.