API keys
Issuing, scoping, rotating, and revoking organization API keys — and treating a key as a user rather than as a setting.
How-toFor Developers, Business owners, Firm staff
How keys work
The public API authenticates every request with an organization API key. Keys are stored hashed — the full value is shown once, at creation, and cannot be retrieved afterwards. If it is lost, issue a new one and revoke the old.
Practice worth following
- One key per integration, never one shared key for everything — otherwise revoking a compromised key breaks unrelated systems.
- Name keys after the system that holds them, not after the person who created them.
- Store keys in a secret manager or environment variables, never in source control or a spreadsheet.
- Rotate on a schedule, and immediately when anyone with access to a key leaves.
- Revoke keys for retired integrations rather than leaving them dormant.
Rotating without downtime:
- 1
Issue a new key alongside the existing one.
- 2
Deploy the new key to the integration.
- 3
Confirm traffic is arriving under the new key.
- 4
Revoke the old key.
Common questions
Issue a new one and revoke the old. Keys are hashed at rest, so nobody can retrieve the original — including support.
Revoke it immediately, issue a replacement, and review the audit trail for activity attributed to it. Revoking first and investigating second is the right order.
Was this useful?