Authentication
How Sirius API keys work — scopes, storage and rotation.
Every request to the Sirius API (except GET /v1/health) must carry an API
key in the Authorization header:
curl https://api.thesirius.ai/v1/agent/runs \
-H "Authorization: Bearer $SIRIUS_API_KEY"API keys
Keys are prefixed sirius_sk_ and are shown once at creation — store
them immediately in a secret manager. Keys are scoped to a workspace; every
run created with a key belongs to that workspace.
Key management is currently handled by the Sirius team; self-serve creation and revocation from the dashboard is on the roadmap and will be announced in the changelog.
Storing keys safely
- Keep keys in a secret manager or your platform's encrypted environment variables — never in source control.
- Use one key per deployed service, so a leak is contained and revocation is painless.
- Log request IDs, never the
Authorizationheader.
Failure modes
| Status | Code | Meaning |
|---|---|---|
401 | unauthorized | The key is missing, malformed or revoked. |
429 | rate_limited | Too many requests — honor the Retry-After header. |
A 401 on a previously working key almost always means it was rotated:
fetch the current key from your secret manager and retry.
Rotating a key
- Request a new key.
- Deploy it to your services (both keys stay valid during the overlap).
- Revoke the old key and watch for
401s — anything still failing was missed in step 2.