Rotate or revoke an API key

API keys are long-lived bearer tokens, so rotating them on a schedule — and revoking them immediately when one leaks — is worth doing properly. This article walks through both cases.

Rotate a key without downtime#

Rotation means issuing a new key before you retire the old one, so there's no gap where your integration is unauthenticated.

1. Go to Settings → API keys and click Generate key.
2. Give the new key a name that makes the purpose clear (e.g. production-v2).
3. Pick the same role as the key you're replacing.
4. Copy the token — it's shown only once.
5. Update your environment variable or secret manager with the new token and deploy.
6. Once the new key is live and confirmed working (check the Last used column — it should flip within minutes), return to Settings → API keys and click Revoke on the old key.

Keep the old key active until you're sure the new one is working. If you revoke too early and the deploy hasn't rolled out, traffic will hit 401s.

Revoke a leaked key immediately#

If a key is exposed — pushed to a public repo, leaked in logs, included in a client-side bundle — revoke it first, investigate second.

1. Settings → API keys, find the key by its name or prefix (the prefix is visible in the table even though the full token is not).
2. Click Revoke. Revocation propagates to all regions within 60 seconds.
3. Issue a replacement key and update your secrets.
4. Check the Last used timestamp on the revoked key to estimate how long it was exposed and whether you need to audit for unexpected activity.

Revoked keys are stored in the table with a revoked badge so you have a record. They cannot be re-activated.

Update secrets safely#

The standard pattern is to store keys in environment variables, not in code:

# .env.local (never committed)
ELIDO_API_KEY=elido_live_xxx...

import { ElidoClient } from "@elido/sdk";

const client = new ElidoClient({ apiKey: process.env.ELIDO_API_KEY! });

For CI pipelines, use your platform's secret store (GitHub Actions secrets, GitLab CI variables, etc.) and rotate whenever a member with access leaves the team.

What happens to live integrations#

When you revoke a key, any in-flight request that already sent the token will still complete — we validate at request start, not mid-response. Requests that begin after revocation return 401 Unauthorized. The SDKs do not retry on 401 (that would loop), so your integration will start failing immediately.

Plan for a brief overlap window: keep the old key alive until you've confirmed the new one is active in production.

Troubleshooting#

401 on a key I just created. The token shown at creation time is the full key including the secret suffix. If you copied only the prefix from the table (e.g. elido_abc123), that won't work — the prefix is display-only. Re-issue a new key and copy the full token.

Revoke button is missing. The key is probably already revoked. Revoked keys show a revoked badge and no action button. Check that you're looking at the right workspace — keys are workspace-scoped.

60-second propagation window. If you revoked a key and requests are still succeeding for a moment, that's expected. Our edge nodes sync revocation via Redis pub/sub; worst-case lag is ~60 seconds.

Key disappeared from the list. We keep revoked keys in the table indefinitely for audit purposes. If you can't find it, check that you haven't filtered the list — there's no active-only filter by default, but a text search on the name field will hide non-matching rows.