A request returns 401 authentication_error. What is the most likely cause, and what is the fix?
Why C is the answer
The key is malformed, revoked or expired, so replace it
401 means the key failed authentication, and retrying will not change that. A valid key without access to a resource gets 403 instead.
In detail
- 401 means the key failed authentication.
- Retrying sends the same bad key, so it has to be replaced.
- A valid key without access to a resource gets 403 instead.
- Alert on any 401 in production, because it will not clear by itself.
Use case
An illustrative scenario, not a real incident.
A key is rotated, but one service keeps the old one, and all its calls return 401. Retries change nothing. Updating the secret fixes it at once.
See it in different ways
flowchart TD
A{"Which status?"} -->|"429, 500, 529"| B["Back off with jitter and retry"]
A -->|"400, 401, 403, 404, 413"| C["Fix the request or credentials"]
B --> D{"Still failing?"}
D -->|Yes| E["Contact support with the request ID"]mindmap
root((API errors))
400
Invalid request
401
Bad key
403
No access
429
Rate limit
529
Overloadedflowchart TD
Q{"What did you receive?"}
Q -->|"401"| A0["Key failed, so replace it"]
Q -->|"403"| A1["Valid key, no access to the resource"]
Q -->|"429"| A2["Back off"]Key point: A 401 needs a new key, not a retry.
Why the other options are wrong
- A. The account lacks a model, so request access
- Missing access to a resource returns 403 rather than 401.
- B. The API is overloaded, so retry with backoff
- Overload returns 529. Backoff will not fix a bad key.
- D. The prompt is too long for the model, so trim the oldest messages in context
- A prompt that is too long returns 400.