Rotating and Revoking an API Key

Rotate API keys on a schedule (good hygiene) or revoke them immediately if you suspect one's leaked (good incident response). This page covers all three options:

• Rotating: replacing an old key with a new one in a planned swap.
• Deactivating: a soft pause. The key stops working but stays on file so you can flip it back on.
• Deleting (revoking): permanent. The key is destroyed and gone for good.

• You need to be an owner, admin, or have a role that matches the key's scope category (see Roles and Permissions).
• Read-only members can't manage keys at all.
• If you're deleting a key, services using it stop working immediately. Plan accordingly - for a rotation, create the new key first.

There's no in-place rotate button. The pattern is create new, swap consumer, then revoke old.

1. Follow Creating an API Key to make a new key.
2. Use the same name as the old key with a version suffix - like CI/CD pipeline v2.
3. Give it the same scopes, the same IP allowlist, and the same expiry as the old key.
4. Copy the new key value before closing the dialog. There's no way to retrieve it later.

1. Update the secret in whatever service uses the key - your CI variables, your infra-as-code secrets, your monitoring tool's config, your .env file, etc.
2. Deploy or restart the service so the new value takes effect.
3. Keep an eye on the Activity tab on the API Keys page - once you see the new key picking up requests and the old key going quiet, you know the swap worked.

Now that nothing's using the old key, delete it. See Deleting (revoking) a key below.

Deactivation is a soft pause. The key stops being accepted by the API, but it stays in the list and you can flip it back on later without changing its value.

It's useful when:

• You suspect a key is being misused but want to keep it around for forensic review.
• You're putting a service into a maintenance window.
• You want to test what breaks before you commit to deleting the key entirely.

1. Open the API Keys page (sidebar > API Keys under your organization).

2. Find the key in the list. On the right side of each row, there are three action icons:

• Pencil: edit the key (name, scopes, IP allowlist).

• Ban icon: deactivate.

• Trash icon: delete.

3. Click the ban icon on the row.

4. The status badge on the row flips from green (Active) to red (Inactive), and a toast appears: API key deactivated.

The key still exists, but every request using it now gets rejected with a 401. Anything authenticating with this key stops working right away.

1. Find the deactivated key in the list. The ban icon on its row has been replaced with an undo icon.

2. Click the undo icon to flip the key back to Active.

If you've hit the 10-active-key cap in the meantime, reactivation will fail until you delete or deactivate something else to free a slot.

Deletion is permanent. The key value is destroyed - nothing can recover or reactivate it. You'd do this when:

• You've finished rotating away from the key and confirmed nothing still uses it.
• You've confirmed a key has leaked.
• The service the key belonged to is gone.

1. On the key's row, click the trash icon on the right.

2. A confirmation dialog opens. It names the key explicitly and warns: Any service using this key will stop working immediately.

3. Slide the Slide to remove rail to the right.

4. The key is gone. Anything using it gets a 401 on its next request. The row disappears from the list (it's still visible in the activity log as a historical event).

If you have any reason to think a key has been exposed publicly or misused:

1. Revoke first, investigate second. Delete the key now. You can always create a new one. Every minute the leaked key stays valid is a minute it can be abused.
2. Check the Activity tab. Owners and admins can switch to the Activity tab on the API Keys page to see exactly which endpoints the key has been hitting, from which IPs, and when. Look for unfamiliar paths, unusual IPs, or volume spikes.

3. Audit the blast radius: Open the activity log at Organization > Settings > Activity and scan for any mutations made via the key over the suspected exposure window. Reverse anything that looks wrong. 
4. Rotate related credentials: If the leak source was a config file or a CI environment, anything else stored in the same place is also suspect - rotate those too.

Every key event leaves a trace:

• Create, edit, deactivate, reactivate, delete, IP-allowlist change - all show up in Organization > Settings > Activity.
• Every request the key makes - owner and admin only, visible on the Activity tab of the API Keys page. Shows HTTP method, path, status, duration, and source IP.

On key creation, a confirmation email also goes out to you, copied to the organization's billing recipients, so any unexpected key creation gets noticed.