401 invalid_api_key: The Five Real Causes (and the One-Line Check)

Figures on this page were verified 31 August 2026 against the providers' own documentation. Pricing, context windows and rate limits change without notice, so confirm any number against the provider before you rely on it. Tell us if something here is out of date.

A 401 means the key never reached the server in a form it recognised. In practice it is almost never a “wrong key” and almost always one of five mechanical causes: a stale environment variable, whitespace in the key, the wrong header, a key from a different organisation, or a key that was rotated out from under you. Work through them in that order.

What each provider returns

OpenAI      401  "code": "invalid_api_key"
                 "Incorrect API key provided: sk-...XXXX"

Anthropic   401  "type": "authentication_error"
                 "invalid x-api-key"

Note that OpenAI echoes the last few characters of the key it received. That is the single most useful diagnostic on the page: compare those characters against the key you think you are sending. If they do not match, your process is not reading the variable you edited.

The five causes, in order of likelihood

1. The process is holding a stale value

Environment variables are read at process start. Editing .env and saving does nothing to a server that is already running, and a shell that exported the old value keeps it until you open a new one. Restart the process, not just the file.

In notebooks this is especially sticky, because the kernel outlives your edits. Restart the kernel.

2. Invisible whitespace

A trailing newline from a copy-paste, or quotes that became part of the value, will fail authentication while looking perfect in a log. This is the classic:

# wrong: the quotes become part of the value in some loaders
ANTHROPIC_API_KEY="sk-ant-..."

# wrong: trailing space
ANTHROPIC_API_KEY=sk-ant-...

# right
ANTHROPIC_API_KEY=sk-ant-...

Check the length rather than eyeballing it. len(os.environ["ANTHROPIC_API_KEY"]) against the length of the key in the console tells you immediately.

3. The wrong header

The two providers do not use the same authentication header, and code ported from one to the other fails here.

Sending an Anthropic key on Authorization: Bearer returns a 401 that looks identical to a bad key. If you are using the official SDK you never touch this, which is a good argument for using it.

4. Right key, wrong organisation or project

Keys are scoped. A valid key belonging to an organisation that lacks access to the model, or a project you are not billing, fails authentication or authorisation in ways that read like a bad key. If you hold several accounts, confirm which one issued the key you are sending.

5. The key was revoked or rotated

Keys get rotated by teammates, revoked by automated secret scanning when they leak into a public repository, or expire with a departing employee’s account. If the key worked yesterday and nothing in your code changed, check whether the key still exists in the console.

Secret scanners are fast. A key pushed to a public repository can be revoked within minutes, which produces exactly this error with no other warning.

A diagnostic that settles it in one call

Take your application out of the picture and test the key directly. If this succeeds, the key is fine and the problem is in how your code loads it.

curl https://api.anthropic.com/v1/models 
  -H "x-api-key: $ANTHROPIC_API_KEY" 
  -H "anthropic-version: 2023-06-01"

Run it in the same shell your application runs in, using the same variable, so you are testing what the process actually sees rather than what you believe it sees.

Do not retry a 401

Authentication failures are deterministic. The same key will fail identically forever, so retry logic only delays the error and multiplies your logs. Fail fast, surface it clearly, and keep 401 out of whatever backoff wrapper handles 429 and 529.

While you are in there

• Never commit keys. Use environment variables or a secret manager, and add .env to .gitignore before the first commit rather than after.
• Log the last four characters if you must log anything, never the key.
• Use separate keys per environment so revoking a leaked development key does not take production down with it.

Related

If the key is valid but requests still fail, the next suspects are 429 rate limits and quota errors and context_length_exceeded.

This page is part of our LLM API error reference, which covers every common error across OpenAI and Anthropic and whether each one is safe to retry.

Frequently asked questions

My key is definitely correct, so why do I still get a 401?

Five causes cover almost every case: whitespace or a newline copied along with the key, the wrong header (Authorization Bearer for OpenAI against x-api-key for Anthropic), a key that has been rotated or revoked, a key belonging to a different organisation or project than the resource you are calling, and an environment variable that is not actually loaded in the running process.

How do I test a key in one line?

Call the models endpoint with curl and nothing but the auth header. If curl succeeds and your application still fails, the key is fine and the problem is in your code or your environment loading, which narrows the search enormously.

Is a 401 ever the provider's fault?

Almost never. A 401 means authentication was presented and rejected, which is a property of your request. Provider-side problems surface as 500, 503 or 529 instead.