SigSentry Documentation

Stop a key from working immediately, rotate cleanly without downtime, and respond to a leaked credential

Revoking a key takes effect immediately and cannot be undone. The key stays in the dashboard for the audit trail, but any request carrying it is rejected.

Where to revoke

Project → API Keys → ⋯ → Revoke for project-scoped keys. Organization → API Keys → ⋯ → Revoke for tenant-scoped keys. A confirmation prompt appears before the revoke goes through.

What happens when you revoke

Behaviour	Detail
Effect	Immediate. New requests with the key are rejected.
In-flight requests	Requests already accepted by the API finish normally. New requests using the same key are rejected with `401 Unauthorized`.
Reversibility	None. A revoked key cannot be reactivated — create a new one if you need access again.
Visibility	The key remains in the API Keys table with a Revoked status, so the audit trail stays intact.

A failed request from a revoked key returns the standard error envelope:

{
  "success": false,
  "error": {
    "code": "UNAUTHORIZED",
    "message": "API key is revoked"
  }
}

Rotation: replace a key without downtime

Don't revoke a key your application is still using. Instead, create the replacement first, switch traffic over, confirm, and only then revoke the old key.

Create the new key

In the same project (or organization), create a new key with the same permission list as the one you're rotating. Copy the full value to your secret manager. See Creating keys.

Deploy the new key

Update your application or CI to read the new key. Deploy and verify the deploy succeeded.

Confirm the new key is working

In the dashboard, watch the Last Used timestamp on the new key — it should update within seconds of your application making a request. If it stays empty, your deploy is still using the old key; investigate before continuing.

Revoke the old key

Once the new key shows recent activity, go to the old key and click Revoke. The next request from any code path still using the old key will fail loudly — which is what you want, so you can find and fix it.

Rotate on a schedule, not just after incidents. A 90-day rotation cadence is reasonable for most teams. The dashboard surfaces a warning on any active key whose Last Used is more than 90 days ago — those are good rotation or revocation candidates.

Responding to a leaked key

If you suspect a key has been exposed — pasted in a public repo, shared in a screenshot, sent over an unencrypted channel — treat it as compromised even if you can't confirm misuse.

Create a replacement first

The rotation procedure above. Get a new key in place before you revoke, so you don't take production down while you're firefighting.

Revoke the leaked key

Once the replacement is live and showing Last Used activity, revoke the old one.

Audit the Last Used timestamp on the leaked key

Compare against your expected usage. A timestamp from outside your deploy windows or from a region you don't operate in is a strong indicator the key was used by someone else.

Check the dashboard's audit log and recent analyses for actions you don't recognise. If the leaked key had config:write, also review log sources, channels, and watchdog rules for unexpected changes.

Once a key is in a public place, deleting the post or commit is not enough. Search engines, archives, and forks may still have it. Revoke first, clean up second.

Stale-key warnings

The API Keys table flags any active key whose Last Used is more than 90 days ago. A long-dormant key is rarely safer than a current one — it just means a credential is sitting around with nobody watching it. Either confirm it's still needed and put it back to work, or revoke it.

Revoking keys