Passing your key
Either header works:
Authorization: Bearer zm_live_aB12C3...# orX-Api-Key: zm_live_aB12C3...
Prefer Authorization: Bearer — it works with proxies, OpenAPI generators, and most HTTP-client middleware out of the box.
Who can mint a key
| Plan | Mint keys |
|---|---|
| Free | no |
| Pro | yes |
| Enterprise | yes |
All keys are prefixed zm_live_.
Key cap
You can hold two active keys at once — enough for zero-downtime rotation: mint the new key, deploy, then revoke the old one. A third active key returns 409 key_limit_reached.
Rotation
- Create a second key in Profile → API keys.
- Deploy it. Both keys are valid in parallel.
- Watch
lastUsedAton the old key. Once stale, revoke it.
Storage
Plaintext is never stored. Each key is hashed with a per-key salt using SHA-256; only the hash and the public prefix live in the database. The plaintext is shown exactly once, at creation.
Errors
| Status | error.code | Cause |
|---|---|---|
| 401 | invalid_api_key | Missing, malformed, or revoked. |
| 403 | plan_forbidden | Plan lacks API access or a specific endpoint feature (e.g. hourly-data). |
| 409 | key_limit_reached | Tried to mint a third active key. |
| 429 | quota_exceeded | Monthly hard cap hit. |
See Errors for the full envelope.
CORS
All data endpoints respond with Access-Control-Allow-Origin: * and Allow-Credentials: false. The bearer key is the auth boundary; origin restrictions add no meaningful protection and would break notebook and AI-agent clients.