Managing API keys

Settings → API keys. Keys authenticate machines, not people: they carry the permissions of the workspace they were created in, not of the person who created them.

Creating one

Give it a name that says where it will be used, so that in a year you know what "key 3" was for. The secret is shown once, at creation. If you lose it, revoke it and make another; there is no way to see it again.

One key per integration

It is tempting to reuse a single key everywhere. Do not. A key per integration means:

• You can see in the usage chart which one is doing the traffic.
• You can revoke one without taking the others down.
• A leak has a smaller blast radius.

Rotating without downtime

Keys are independent, so rotation needs no coordination:

1. Create the new key.
2. Deploy it to the integration.
3. Confirm traffic on the new key in the usage chart.
4. Revoke the old one.

If a key leaks

Revoke it immediately from Settings → API keys. Revocation takes effect at once, including for requests already in flight. Then check the audit log for what was done with it, and rotate anything the key could have reached.

Keys are stored hashed, so a leak of our database does not expose your key, but a key pasted into a public repository or a support ticket is exposed and should be treated as burned.

Limits

Your plan caps how many keys a workspace may have, and each key carries the workspace's per-minute and daily limits. See Rate limits and quotas.