API keys
Mint, name, rotate and revoke keys for a honeycomb. Why we use multiple keys and how to recover from a leak.
Every honeycomb has a primary API key (sk_…) created when you first set up the project. You can mint additional keys later for rotation, multi-environment setups, or to give a third-party integration its own scoped credential.
All keys for a honeycomb grant the same operation: POST a bug report to that honeycomb. There's no read access, no settings access, no cross-honeycomb access. The keys differ only in identity — you can tell which one a request used by the prefix shown in the dashboard.
Where to find them
/{hive}/honeycombs/{id}/settings/api-keys lists every key for the project:
- Prefix (first 12 chars of the key) — what shows in the list. We never re-display the full key after creation.
- Name — your label for the key (e.g. "Marketing site", "Staging env").
- Created at / last used at — quick way to spot stale keys.
- Actions — copy prefix, revoke.
Minting a new key
Click Generate key, name it, and copy the plaintext immediately — we hash it before storing, so once you leave the modal we can only show the prefix.
Rotating
To rotate without downtime:
- Mint a new key, name it (e.g. "Production v2").
- Update your widget snippet / env var to use the new key.
- Wait until the old key's last used at stops moving (a few minutes for client-side widgets, longer for server-side integrations that POST in batches).
- Revoke the old key.
The old key stops working immediately on revoke — no grace period. Time the revoke to when you're confident nothing legitimate still uses it.
Recovering from a leak
If you suspect a key is being abused:
- Revoke immediately — stops further damage.
- Mint a replacement and update your snippet.
- Skim the inbox for spammy reports submitted with the leaked key (they'll match a window of time + a sudden volume burst). Bulk-mark spam and they're out of your queue.
- If you want to block specific reporters going forward, add blocklist rules — see Blocklist.
The 60-reports/minute/key rate limit caps how much damage a leak can cause in real time. Our transparency note on the widget page expands on the threat model.
Legacy single-key projects
Honeycombs created before the multi-key migration carry a legacy api_key column with their original key. The dashboard treats it as the implicit primary; minting your first additional key doesn't invalidate the legacy one. Eventually we'll deprecate the legacy column and require the explicit table — when we do, you'll get a migration prompt; nothing breaks until you act on it.