OpenAI adds project-key expiry and key-creation restrictions
OpenAI documents configurable project-key expiration and maximum lifetimes on September 10, and new-key creation restrictions on September 15. Organization restrictions bound project settings. Existing keys are unaffected by creation controls; this is no guarantee against expiration or revocation.
Kingy verdict
OpenAI project-key automation needs to respect configured expiry limits and permitted key types. Check those policies before rotating credentials: creation restrictions can block a replacement. Existing keys are unaffected by creation controls, but can still expire or be revoked.
Required action
Review automation that creates or rotates project API keys against organization and project lifetime limits and permitted key types. Before an actual key expiry, create an allowed replacement, update applications, verify it works, then revoke the old key. If creation is disabled or the needed key type is prohibited, resolve that policy dependency before attempting rotation.
September 10: expiration and maximum lifetimes
The September 10, 2026 changelog notice documents expiration dates when creating project API keys and administrator-configured maximum lifetimes. New keys must expire within the configured maximum. A project cannot set a longer lifetime than its organization allows. The evidence establishes neither a numeric default lifetime nor retroactive expiry dates for existing keys.
September 15: restrictions on new-key creation
The September 15, 2026 notice documents three creation policies: service-account keys only, user-owned project keys only, or no new keys. Organization restrictions take precedence. Projects may add restrictions but cannot loosen the corresponding organization policy. Existing keys are unaffected by these creation controls; that does not protect them from expiration or revocation.
Check policy before rotation
OpenAI recommends creating a replacement, updating applications, verifying that it works, then revoking the old key. Operational inference: disabling new-key creation or prohibiting the required key type can obstruct that replacement workflow. Resolve the policy dependency with the appropriate administrator before attempting rotation. Kingy has not tested this consequence against an account.
Diagnose authentication failures without guessing
The error reference describes invalid, expired or revoked credentials as possible authentication failures. This review establishes no dedicated project-key expiry error code. An authentication failure alone does not prove that an expiry or governance setting caused it. Do not transfer project-key policy behavior to OAuth, Admin API keys or other credential surfaces.
Two notice dates, no universal deadline
September 10 and September 15 are separate documented notice dates. No universal expiry or mandatory migration deadline is established, and this record adds no calendar milestone. Historical first-detection date is unverified. Publication and source-check dates do not establish when Kingy first detected this change. These controls create conditional operational risks when configured; this is not an automatic breaking change for every existing integration.
Evidence limits
Kingy has not accessed account settings, key material, administrator entitlements, plan availability or private telemetry. No key was created, rotated, used, revoked, tested or expired. The evidence does not establish a universal outage, enforced organization policy or complete rollout.