Authentication
API keys, the header, and what a key can reach.
Every request carries your key in the X-Api-Key header:
X-Api-Key: hs_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxThere are no scopes or permissions. A key either authenticates or it does not, and every key reaches every endpoint.
Managing keys
Keys live in the dashboard. Create as many as you have places to run code — one per environment or service makes revoking a leaked key a small event rather than an outage.
The plaintext is shown once, at creation. We store a SHA-256 hash and an eight-character prefix, so after that we can tell you which key a row is but not what it says. If you lose one, revoke it and create another.
Revoking is immediate in intent and takes effect within about thirty seconds in practice: the API caches the active key set in memory and refreshes it on a timer rather than querying the database on every request.
What comes back on every response
| Header | Meaning |
|---|---|
x-request-id | Unique per request. Quote it in support threads — it is how we find your call in the logs. |
Rate limits
10 requests per second per key. Exceeding it returns
429 with a Retry-After hint
in the message, and costs nothing.
The limit is per key, not per account, so splitting work across several keys raises your ceiling. If you need a higher ceiling on one key, ask.
Keeping a key safe
- Keys are bearer credentials. Anyone holding one can spend your balance.
- Never ship one in browser JavaScript, a mobile app, or a public repository. Call the API from your own backend and keep the key there.
- Rotate by creating the new key, deploying it, then revoking the old one — in that order, so there is no window without a working key.
The unauthenticated endpoint
GET /system/health needs no key. It is a liveness check and
returns {"status": "ok"}. Everything else requires one.