How to rotate an OpenAI API key

Create a new API key in the same project with the same permissions, deploy it, check that requests succeed with it, and only then revoke the old key. A project can hold several keys, so both work during the switch. OpenAI describes the same order for planned rotation: before a key expires, create a replacement, update your applications, and revoke the old key once you've verified the replacement works (OpenAI docs). Revocation is quick: the API reference says it takes effect within a few seconds (API reference).

Crunu doesn't create or revoke OpenAI keys and has no integration with the OpenAI platform. Its job is to show which OpenAI values a departing person received, to store the new key as a new version of the environment, and to restart the programs that read it.

Which OpenAI key you hold

OpenAI separates two kinds of credentials. A standard API key authenticates application requests. An Admin API key works with the Administration endpoints, which manage users, invites, projects, API keys and audit logs. An Admin key is the more dangerous of the two, so reissue it on its own, with fewer people involved.

Standard keys live in projects, and a project is the workspace for its keys, files and resources. Inside a project a key can be owned by a user or by a service account, which only organization owners and project owners can manage (permissions guide). Permissions are checked twice: for a request in a project, OpenAI takes the permissions assigned to the key and also checks that its user has a project role granting them. OpenAI's own example: the key must have api.model.read assigned, and its user must hold a project role with api.model.read.

Legacy user API keys may need the OpenAI-Organization and OpenAI-Project headers to choose where usage counts. If you still have one, a reissue is a good moment to replace it with a project key.

Reissue without downtime

crunu run --env web-app/production -- sh -c \
  'curl -s https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY"'

If the new key is restricted and has no permission to read models, use a request your application actually makes instead.

Keys that expire, and who may create them

OpenAI strongly recommends setting an expiration date on every project API key and keeping a regular rotation process. Administrators can enforce a maximum lifetime at organization or project level, and new keys must then expire within it.

API key governance adds a second control: administrators can allow only service account keys, allow only user-owned project keys, or stop new key creation altogether. Organization rules take precedence over project rules. These controls apply only to new keys, so existing keys still need a reissue to fall under them.

When to reissue an OpenAI key

• Someone leaves. OpenAI's documentation doesn't say what happens to a user-owned key when its owner is removed, so don't rely on it. Revoke the keys they owned and reissue every shared key they could read. In Crunu, removing them produces a reissue checklist that names those variables, and Where to reissue links to OpenAI's key page for recognized OpenAI values.
• A leak. Revoke the key at once. A few seconds later it's useless, and you deploy the replacement afterwards.
• A schedule. An expiration date turns rotation into a routine you can't skip. OpenAI also advises reviewing keys regularly, removing unused ones and rotating sensitive ones.

Keep production on service account keys: a key that belongs to a person and their project role is tied to that person's membership. What to rotate when a developer leaves covers the full order of work, and the offboarding checklist builds the list for your stack. On the Crunu side, each saved version shows when the new key arrived; the key itself is always created and revoked in the OpenAI dashboard.