OpenAI API Key Expiry Needs a Rotation Plan

OpenAI gave project API keys an expiration date on September 10, 2026. That turns credential rotation into scheduled production maintenance: an unattended agent now needs an owner, a replacement window, and a verification step before its key runs out.

The change is a deadline, not automatic rotation

An API key is the secret an application sends to prove it may use the OpenAI API. Teams often place one in a secret manager, point a scheduled worker at it, and leave the worker alone until something breaks.

OpenAI now lets you set an expiration date when you create a project API key. An administrator can also set a maximum key lifetime in Platform settings at the organization or project level. If that policy exists, newly created keys must expire within the allowed lifetime.

These controls do different jobs:

The parent rule matters. A project setting cannot make a key live longer than the organization policy permits. The project has to stay inside that boundary.

This is not an automatic rotation system. OpenAI's production guidance tells you to create a replacement before expiry, update the applications, verify the replacement, and only then revoke the old key. Your team still owns every handoff in that sentence.

The business change is a maintenance budget

The feature does not change token prices. It changes the labor and interruption math around every scheduled job that authenticates with a project key.

Here is a simple planning model. These are workload assumptions, not OpenAI limits.

Assume one project has an agent scheduled every 15 minutes, or 96 runs per day. A planned rotation takes 30 minutes of operator time. If the team chooses a quarterly schedule and values loaded operator time at $75 per hour, rotation costs $37.50 each and $150 per project per year. Ten projects turn that into a visible $1,500 annual maintenance line.

Now assume a key expires unnoticed and the interruption lasts 4 hours. That window contains 16 scheduled starts. If each missed run takes 10 minutes to inspect and replay, recovery takes 160 minutes, or 2 hours 40 minutes. At the same $75 rate, labor alone is $200, before delayed customer work, missed reports, or lost revenue enter the calculation.

That is the consequence. Expiration reduces the time a forgotten credential can remain valid, but it converts a hidden security risk into a recurring operating task. The task needs time in the budget and a named person on the calendar.

If the real concern is runaway API spend, key expiry is the wrong control. The separate AI Agent API Budget Controls guide covers that boundary. A budget cap and a credential deadline can both interrupt work, but they solve different problems and need different recovery plans.

Who needs this workflow

A solo founder with an unattended SaaS agent

A founder running a support summary, document processor, or data-enrichment job should attach the credential to an owner, even if that owner is the founder. Record which scheduler, deployment, and secret entry use the key. Start the replacement while the current key still works, then watch a real scheduled run finish on the new secret.

The payoff is continuity. The rotation becomes a small planned release instead of a customer reporting that yesterday's work never arrived.

An agency operations lead with client projects

An agency can give each client project its own rotation record: project, key owner, deployed jobs, expiration, replacement status, and verification result. That makes the labor countable. It also stops one forgotten client automation from hiding inside a shared credential nobody wants to touch.

The payoff is margin protection. Rotation time can enter delivery planning, and the account lead knows which client jobs need checking before the old secret disappears.

A platform team setting the organization rule

A backend or platform team should decide the organization maximum first, then let individual projects adopt a limit that stays inside it. The team can use a shorter project policy where the workload or risk calls for one, but it cannot use a longer project lifetime to escape the organization ceiling.

The payoff is consistent governance. The same team should publish the replacement procedure at the moment it publishes the lifetime rule. A deadline without a handoff is just a future incident with a date attached.

A security administrator cleaning up older credentials

A security administrator should treat the new-key policy and the old-key inventory as two tracks. Enforce the maximum lifetime for newly created keys, then separately find existing project credentials and assign owners. The published scope does not promise that those older keys will expire on their own.

The payoff is an honest rollout. The organization improves new credentials immediately without confusing a forward-looking policy with a completed cleanup.

Rotate one key without creating a gap

The exact deployment buttons depend on your host and secret manager. The safe sequence does not.

1. 1

   Confirm the policy and the owner

   Check the organization maximum and the project's maximum before creating the replacement. Record the current key's project, every job that uses it, the person responsible, and the point when the replacement work begins.

2. 2

   Create the replacement early

   Create a new project API key while the old key is still valid. Give the replacement an expiration that complies with the active policy. Do not put it in source code or a public repository.

3. 3

   Stage it through the secret store

   Save the replacement as a new version in the environment variable or secret-management path your application already uses. Update one controlled worker or test path first. OpenAI also supports separate staging and production projects when you need stronger isolation between testing and live work.

4. 4

   Verify the deployed job

   Run the application through its real authentication path. Check the request result, the job output, the queue, and the worker logs. OpenAI's Usage page can provide another signal once key tracking is enabled, but a dashboard view does not replace checking the business result.

5. 5

   Roll forward, then retire

   Update every deployment, scheduler, CI secret, and long-running worker that used the old credential. Confirm that the new key works across those jobs. Revoke the old key only after that verification is complete.

What the feature still leaves with you

OpenAI's public pages do not state a universal default lifetime or one fixed maximum duration. They also do not describe a grace period, an automatic replacement mechanism, or an expiry-notification schedule. Your account settings define the policy, and your operating system around it has to carry the reminder and rollout.

The setting also cannot tell you where a secret was copied. It does not know that a developer pasted the key into a CI system, a serverless environment, a local machine, and a backup script. Inventory is the part most teams will underestimate.

Verification is the other hard part. A successful test request proves that the replacement is valid. It does not prove that every scheduled worker received it. That is why the job list belongs in the rotation record and why the old key stays valid until the list is checked.

What to do this week

Act now if a scheduled agent, batch worker, customer automation, or backend service uses a project API key and your organization plans to enforce a maximum lifetime. Put the rotation workload in the operating budget before the policy creates the first deadline.

You can wait on a full rollout if no maximum lifetime is enabled and no current project key has an expiration date. Still inventory the credentials and owners now. The new control makes the eventual direction clear, and OpenAI already recommends regular rotation.

Existing keys are not described as retroactively expiring, so there is no basis for claiming every old deployment suddenly has a September deadline. That is not a reason to ignore them. It is a reason to inspect them separately instead of trusting the new policy to clean up the past.

On Monday, choose one production project. Assign the credential to an owner, stage a replacement while the current key still works, check every deployed job on the new key, and then retire the old one. That four-part handoff is the rotation plan.

For more plain-language operating notes like this, join the newsletter.