Error messages

invalid x-api-key

invalid x-api-key

The Claude API sends this back when the key on a request doesn't work. Called with curl, the whole response looks like this (copied from a June 2026 bug report, request id shortened by its author):

{"type":"error","error":{"type":"authentication_error","message":"invalid x-api-key"},"request_id":"req_..."}

The HTTP status is 401. Through Anthropic's Python SDK you get it wrapped, as an anthropic.AuthenticationError whose text starts with the status:

Error code: 401 - {'type': 'error', 'error': {'type': 'authentication_error', 'message': 'invalid x-api-key'}, 'request_id': 'req_...'}

We read that formatting in anthropic-sdk-python 1.8.0. It's a busy error: 4,822 GitHub issues and pull requests contain invalid x-api-key as of September 25, 2026 (1,268 of them issues), and 2,151 were opened since June 1.

What the 401 covers

Anthropic's error page says a 401 means "There's an issue with your API key", and gives malformed, revoked and expired as examples. The authentication docs fill in the rest. Keys can be created with an expiry (3 hours up to 30 days, a custom length, or never), and once one lapses every request returns 401 authentication_error for good: "expired keys cannot be reactivated." A key someone disabled in the Console fails the same way until it's re-enabled; a deleted one never comes back. Personal keys are archived when their owner leaves the organization, and legacy workspace keys stop when the workspace is archived.

The message names the x-api-key header because that's the older way of sending a key. The docs now show Authorization: Bearer first but still accept the old header.

A token that isn't an API key

This is the pattern we saw most in 2026 reports. Someone signs in with a Claude subscription, gets an OAuth access token starting sk-ant-oat, and their tool drops it into x-api-key. The API rejects it with exactly this body. The flash-term report traced its 401 on every chat to that, and so did the mika one. A proxy that forwarded a GitHub Copilot token straight to api.anthropic.com got the same answer. A real Console API key starts sk-ant-api; if yours doesn't, that's where to start.

When the key looks right

The SDK picks its key up in an order that catches people. In 1.8.0, passing any credential argument to the client (api_key=, auth_token= and a few others) means it doesn't read environment variables at all. With none passed, it reads ANTHROPIC_API_KEY, then ANTHROPIC_AUTH_TOKEN. So an old key hardcoded in a config file wins over the fresh one in your shell. A stray space or newline pasted with the key makes it malformed too.

If there's no key at all, you won't see this message. The SDK stops before sending anything and raises a TypeError that starts "Could not resolve authentication method."

What to do

Log the first dozen characters of the key your process really sends (never the whole thing), then find it on the API keys page of the Claude Console. If it's expired or deleted, create a new one; if it's disabled, re-enable it. Check that it belongs to an organization and workspace you still have access to.

Don't loop on it. The SDK retries some failures twice by default, but 401 isn't one of them, and neither should your code. One thing surprised us: the error page lists plenty of 401 causes, yet the message text never says which one you hit, so the request id is what support will ask for.