Ingest API keys
How ingest keys are issued, revealed, rotated, and revoked — and what happens to keys issued before reveal support existed.
Ingest keys authenticate telemetry and resolve tenant identity — nothing more. A key is a low-privilege, revocable credential: it can only write telemetry into its own tenant, and grants no dashboard or API access. One key belongs to exactly one tenant.
Issuance
Your first key is issued during onboarding. Additional keys — for separate environments, teams, or Collectors — are created in the dashboard under organization → API keys. Each key is listed with a short prefix so you can tell keys apart without revealing them.
Reveal
Keys are retrievable after issuance: they are stored encrypted at rest and can be revealed on demand from the dashboard or from personalized snippets in these docs. All organization members can reveal keys — the posture matches a low-privilege DSN-style credential rather than a secret API token — and every reveal is audited: who revealed which key, when, and from where. Keys are never placed in URLs.
Rotation
To rotate, issue a new key, move your senders over, and revoke the old one once traffic has drained. Because keys are cheap to create and instantly revocable, rotate whenever you suspect exposure and on whatever schedule your security policy requires.
Revocation
Revoking a key stops it authenticating new requests. The gateway caches key lookups briefly for performance, so revocation takes effect within a short window rather than instantaneously; the exact bound is to be confirmed and will be documented here.
Legacy keys: rotate to enable reveal
Keys issued before reveal support existed were stored only as one-way hashes — they still authenticate, but they cannot be revealed, and the dashboard shows "rotate to enable reveal" against them. Rotating replaces such a key with one that supports reveal.