An API key expiry can become a workflow outage if the replacement exists but one worker still reads the old credential. Updating a secret store does not prove that every process reloaded it. The practical rotation plan therefore covers consumers, actual execution, uncertain outcomes and the point at which the old key can be retired.
This article proposes a controlled runbook. It does not rotate any live credential or promise zero interruption. The security and operational owners approve the actual change window, permissions and recovery path. No secret value should be copied into the runbook or test evidence; use secure references and non-sensitive result records.
Check the expiry and the actual consumers
Record the old credential's secure reference, project, owner and accepted expiry time. Use an unambiguous timezone. Inventory web processes, scheduled jobs, queue workers, local scripts and third-party connectors that use it. Unknown consumers remain an unresolved preflight item, not a reason to assume the main application is the only dependency.
Source: OpenAI API changelog records the September 2026 project-key expiration feature, with the accepted source check identifying the 10 September entry. The live workflow still needs its actual credential expiry and applicable organisation/project limits verified. A feature announcement does not establish a specific key's settings.
Identify which consumers load credentials at startup, on each request or through another tested mechanism. Do not assume hot reload. A restarted worker may also replay a job, so the application needs accepted repeat-processing and recovery rules for its business actions.
Create the replacement under the accepted policy
Source: OpenAI production best practices recommends replacement before expiry, updating applications and revoking the old key after verifying the replacement works. It also describes maximum-lifetime controls for new keys and creation-governance precedence. These are capability and practice references; the organisation approves the precise operational sequence.
Create the replacement through the authorised administrator process for the correct project and accepted ownership type. Verify its permitted purpose and expiration. A replacement in another project or with inappropriate restrictions may authenticate differently or fail the intended operation. Keep the new secret in the reviewed management path and record only its secure reference.
Define the overlap window and rollback limits before the switch. The old credential must remain valid and permitted for any planned rollback. If it has already expired, been revoked or become prohibited, it cannot be a recovery option. Recreating a similarly named key is not restoration of the original credential.
Reusable controlled key-rotation runbook
Use this proposed runbook for one defined operational workflow. The technical and security owners must adapt it to the actual consumers and accepted change controls.
| Stage | Required action and evidence | Stop or recovery condition |
|---|---|---|
| Preflight | Verify old expiry, project, consumers, reload behaviour and business-action recovery | Unknown consumer or untested recovery remains a blocker |
| Replacement | Create authorised new credential and store its secure reference | Wrong project, policy or permission needs correction |
| Isolated verification | Test the intended non-sensitive operation using the new reference | Failure does not trigger blind production retries |
| Runtime preparation | Define update, restart/drain and queued-job handling per consumer | No assumption of hot swapping |
| Controlled switch | Update accepted consumers under the approved plan | Capture exact runtime/version and last completed stage |
| Ordinary verification | Run a representative authorised test and inspect actual result | Authentication alone does not prove workflow completion |
| Failure verification | Check accepted handling of rejected/uncertain requests and alerts | Owner can pause or reconcile without duplicate action |
| Consumer reconciliation | Confirm each runtime is using the accepted new reference | Old-reference consumer remains unresolved |
| Retirement | Authorised owner revokes old key after accepted verification | Rollback to it is no longer available |
| Closeout | Record decisions, residual risks and future expiry owner | Do not claim seamless success without observed evidence |
Rollback record: [Decision owner, permitted old reference, validity limit, runtime reversal procedure and queued-action reconciliation]
Completion check: Every known consumer has attributable replacement verification, old-reference use is accounted for and retirement is a separate recorded decision. A changed secret-store entry alone does not complete rotation.
Verify both authentication and the business workflow
Begin with a controlled, non-sensitive operation appropriate to the intended integration. An accepted authentication response establishes only that part of the test. The normal workflow may also depend on model access, request configuration, tools, queue execution and downstream writes. Inspect the actual result under the authorised test scope.
If the workflow sends messages or creates records, use a test path with controlled destinations and stable operation identifiers. A timeout may mean the external action succeeded without a returned response. Reconcile its outcome before retrying. Do not treat credential rotation as permission to repeat every pending business action.
Keep verification separate for each consumer. A web request using the new key does not demonstrate that a scheduled worker reloaded it. The evidence should identify the tested runtime and secure-reference version without exposing the secret. Agree the observation period and acceptance criteria with the operational owner rather than inventing a universal duration.
Test error routing in the mode that actually runs
Source: n8n Error Trigger describes linked error workflows and notes that the trigger runs for automatic workflow errors, not manual executions. If the integration uses that mechanism, testing a manual run alone does not establish its live alert path. Verify the relevant automatic mode with the approved fixture.
The error workflow also needs appropriate access and non-sensitive logging. Do not include complete credentials in an alert to make troubleshooting easier. A failed authentication event should identify the affected runtime, secure reference and owner, with secrets kept out of message bodies and public logs.
A monitoring success does not prove every consumer switched. Reconcile the inventory and the actual runtime evidence before the old credential is retired. Unknown or dormant jobs may need a separate approved test or retirement decision.
Work through a restarted worker and an uncertain request
In a hypothetical normal case, workflow W-3 has a web consumer and a scheduled worker. The web process supports a tested reload, while the worker reads credentials only at startup. The approved plan updates both references, drains or otherwise handles the worker under the accepted procedure and restarts it. Separate tests establish both consumers' actual results before the owner retires the old key.
Now suppose the worker's test times out after requesting an external task. The runbook leaves that operation uncertain and checks the task record by its stable reference. It does not launch another job with a new identity merely because the API key was recently changed. After reconciliation, the owner decides whether retry or further investigation is appropriate.
An ambiguous consumer creates a preflight failure: a connector's configuration points to a secret label, but staff cannot establish which version it reads. The team verifies that dependency before switching or documents an authorised limited plan. A duplicate inventory row can be linked when identity is established, but a genuine second process remains a separate consumer.
Questions about uninterrupted rotation
Can every client switch credentials without restarting?
No such general guarantee follows from the feature. Verify the actual runtime's reload behaviour. Some processes cache a key at startup or through a connection layer. The runbook needs a tested update/restart or drain procedure and recovery plan for those consumers.
Can we roll back after revoking the old key?
Not to that revoked credential. Rollback must be planned while the old key is valid and permitted, or use another authorised recovery path. Keep retirement as a separate decision after accepted verification rather than assuming it can always be undone.
Is a successful sample request enough to retire the old key?
Only if the accepted verification plan covers every known consumer and required behaviour. One request can miss scheduled workers, tools or error paths. Reconcile the inventory, representative workflow outcomes and outstanding uncertainty before the authorised owner decides to retire the old credential.
If your business needs help defining this process, explore Workflow automation, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.