Every /api/v1/* endpoint authenticates with a project API key sent as a bearer token.The key resolves to exactly one project, and that project scopes everything the request
can see: its connected accounts, its posts, its usage. There is no cross-project read.
Creating a key
Sign in at chirio.dev/auth, then Settings → API keys → Create.
The full key is shown once
Keys are stored as SHA-256 hashes; the raw value is never persisted. If you lose it, revoke the key and create a new one — nobody can recover it, including Chirio.
Key format
chirio_sk_ followed by URL-safe base64 characters. The header must match
Authorization: Bearer chirio_sk_... exactly — a bare key with no Bearer prefix, or a
prefix other than chirio_sk_, is rejected as malformed before any lookup happens.
Revoking
Revoke from Settings → API keys. A revoked key stops working immediately, and is answered
exactly like an unknown one — so revocation leaks nothing about whether the key ever existed.Each key records when it was last used, which is the cheapest way to spot a key nothing has
touched for months.
Failure modes
Status
Code
When
`401`
`unauthorized`
Missing header, wrong prefix, or malformed value
`401`
`unauthorized`
Key is unknown or revoked
Both answer with the standard envelope:
Handling keys safely
Keep keys server-side. A chirio_sk_ key in browser JavaScript hands anyone the ability to
publish as every account in the project.
One key per environment, so staging can be revoked without touching production.
Rotate by creating the new key, deploying it, then revoking the old one — both are valid in
between, so there is no gap.
Dashboard sessions are separate
The dashboard authenticates with magic-link sessions, not API keys. The two never mix: a
browser session cannot call /api/v1, and an API key cannot open the dashboard.
