TKN.

How to revoke an OpenAI API key

Last verified

Console: go to platform.openai.com/api-keys, find the key, click delete, confirm. It stops working immediately and permanently.

That's the whole answer for most people. The rest of this page covers the API method, the per-project case, what breaks when you do it, and how to do it when you're not at a computer.

Method 1 — the console

  1. Sign in at platform.openai.com/api-keys.
  2. Identify the key by its last four characters — the full value is never shown again after creation, which is why every key you hold should be labelled at creation time.
  3. Click the delete (trash) icon on that row and confirm.

For a key owned by a project rather than your user, go to Settings → Project → API keys. You need to be an owner of that project.

Can't tell which key is which?

Delete all of them and reissue. Five minutes of work beats leaving a compromised credential live because you weren't certain. There is no partial credit here.

Method 2 — the admin API

Useful in a runbook, in CI, or when you need to revoke many keys without clicking. Requires an admin key (sk-admin-…) — a normal sk-proj-… key cannot manage other keys.

export OPENAI_ADMIN_KEY="sk-admin-..."

# 1. find your projects
curl -s https://api.openai.com/v1/organization/projects?limit=100 \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY" | jq '.data[] | {id, name}'

# 2. list the keys in one
curl -s "https://api.openai.com/v1/organization/projects/$PROJECT_ID/api_keys?limit=100" \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY" | jq '.data[] | {id, name, redacted_value}'

# 3. delete the one you want
curl -s -X DELETE \
  "https://api.openai.com/v1/organization/projects/$PROJECT_ID/api_keys/$KEY_ID" \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

redacted_value is how you match a key you found in a log or a repo to the key ID you need to delete.

Your admin key is more dangerous than the key you're revoking

An admin key can enumerate and delete every key in the organisation. Keep it out of the same repository, the same .env, and the same CI environment as your inference keys — otherwise a single leak escalates from "one key" to "the whole organisation". See is it safe to give an app your admin key?

Method 3 — from your phone

The case the first two methods don't cover: you find out at the weekend, away from a laptop, and the useful window is minutes.

TKN stores your provider keys in the iOS Keychain behind Face ID and calls the same key-management endpoints shown above. You choose the scope — one key, one provider, or every key it holds — and confirm with a deliberate swipe. Revocation happens at OpenAI, not just in the app.

That's the whole reason the feature exists: the gap between noticing and being at a computer is where most of the money goes.

What breaks when you revoke

Everything using that key starts getting 401 Unauthorized. Specifically:

  • Your production application, immediately
  • Background jobs and cron tasks, at their next run
  • Any teammate with the key in a local .env
  • CI pipelines that call the API in tests
  • Third-party integrations you granted the key to

There is no grace period and no warning email. This is the correct behaviour during an incident — but plan for it if you're rotating on a schedule rather than responding to a leak.

Zero-downtime rotation, when it's not an emergency

For planned rotation, invert the order:

  1. Create the new key first — OpenAI allows multiple active keys.
  2. Deploy the new key everywhere. Every environment, every service, every teammate.
  3. Wait. Give deployments time to roll and long-running processes time to pick it up — 15 minutes is a reasonable floor, longer if you have queue workers with long lifetimes.
  4. Confirm the old key shows no recent usage.
  5. Revoke the old key.

This sequence is wrong during an active compromise. If a key is public, every minute of step 3 is a minute someone else is spending your money. Take the outage.

After revoking

Other providers

Sources

Related