API keys
Tracking keys and read keys: what each one can do and how to handle them.
Two kinds of key
| Key | Looks like | Can |
|---|---|---|
| Tracking key | oa_pk_… | Write events from a browser. Public by design: it goes into your HTML, and it can never read anything. |
| Read key | Shown once at creation | Read the site and its analytics over the read API. A secret: server-side code and scripts only, never a web page. |
Both live under your site's Settings, API tab. Keys are stored hashed; a read key's value exists in your clipboard once and nowhere else afterwards.
Handling read keys
- Create one key per consumer (one for the cron job, one for the internal dashboard), so revoking one thing never breaks another.
- Revoking is immediate. Rotating is create-new, move, revoke-old, with both alive during the move.
- Every key's credential events (created, first used, first used from a new source, revoked) are journalled and visible to the account owner.
When not to use a key
Anything interactive or agent-shaped should use OAuth instead: the CLI signs in with a device flow and MCP clients get scoped, revocable grants. Keys are for headless code you run yourself.