Platform API error
key_expired
key_expired is the Platform API error returned with HTTP 401 when an API key is past its expiry date. Rotate the key in the console to restore access.
Updated November 6, 2026
- HTTP status
- 401
- Code
key_expired
Returned when
- The key carries an expiry date and that time has passed.
What to do
- Rotate it: create a new key in the console, deploy it, then revoke the old one.
Example answer
HTTP/1.1 401
content-type: application/json
{
"error": {
"code": "key_expired",
"message": "This API key has expired. Rotate it in the console."
}
}Related errors
- key_revoked The API key was revoked.
What it means
key_expired means the API key sent with the request carries an expiry date, and that time has passed. The Platform API rejects the call with HTTP 401 and returns the standard error object, where code is key_expired and message reads something like: This API key has expired. Rotate it in the console.
The full response shape is {"error":{"code":"…","message":"…","hint":"…"}}. Codes are stable, so branch on error.code. Never match on the message text, which can change without the code changing.
Why you are seeing it
When a key carries an expiry date and that timestamp passes, the key stops working, even if it was accepted a minute earlier and nothing about your integration changed. From that point on, requests made with it return key_expired.
Typical causes: a key baked into a deployment months ago and never replaced; a rotation you completed in the console but shipped to only some services; a scheduled job or background worker holding its own copy of the old key. Check every place a key is configured, not just the service that logged the error.
How to fix it
Rotate the key. In the console, create a new API key, deploy it to every service that calls the Platform API, then revoke the old one. Keep that order: deploy first and revoke second, so there is no window in which your services are left without a working credential.
Once the new key is live and traffic is running through it, revoke the old key in the console so it cannot be used again. Store the new key's expiry date wherever your team tracks credentials, and set a reminder before it lapses so the next rotation is planned rather than reactive.
Handling it in code
Branch on the code, not the status alone. Several failures come back as 401, and key_expired tells you specifically that the credential needs rotating rather than retrying. Retrying the same request with the same key will keep failing, because the expiry time has already passed.
Treat this as an operational alert, not a transient error. Log error.code and error.hint, stop retrying with that key, and notify whoever owns the credential. If your client caches keys, invalidate the cache so the next run picks up a rotated value.
Handle key_revoked as a separate case. It is a different code with a different cause, so your rotation runbook should name both and your error handling should not collapse them into one branch.
Questions
What HTTP status does key_expired return?
HTTP 401. The response body uses the standard error object with code, message and hint, so read error.code to confirm the failure is an expiry rather than a different authentication problem.
Does creating a new key in the console fix the error automatically?
No. Creating the key is only the first step: you still need to deploy it to every service that calls the Platform API, confirm traffic is running on it, and then revoke the old key.
How is key_expired different from key_revoked?
key_expired means the key is past its expiry date, while key_revoked is a separate code for a different cause. Both are distinct stable codes, so match on error.code rather than message text so each one takes the right path.
Keys, plans and usage live in the console: rotate keys, add webhook endpoints, see the last 30 days.
Written from the OneLifeVibe tool registry and platform configuration, and checked automatically before publishing. Something wrong? Tell us.