Anthropic x-api-key is now a fallback: Sume accepts one header

Anthropic's docs list Authorization: Bearer first and call x-api-key a legacy fallback. Sume accepts either, but rejects a request that sends both with a 401.

4 min readSume
All posts

Anthropic's API overview now lists Authorization: Bearer first and describes x-api-key as a "Legacy fallback for Authorization, still supported". Sume accepts both forms too, but a request carrying both gets 401 unauthorized with Send only one API key credential. Pick one header per integration.

Anthropic's wording is from its API overview; Sume's from Authentication, both read 2026-09-30.

What changed on the Anthropic side?

The overview's header table shows Authorization as Bearer <token> and marks it as needed "unless x-api-key is set". x-api-key is described as your API key from Console, kept as a legacy fallback. Clients that used to send only x-api-key still work there.

Which header does Sume want?

Header behavior as read 2026-09-30 from Anthropic's overview and Sume's authentication page.
RequestAnthropic docsSume docs
Authorization: Bearer onlyListed firstAccepted
x-api-key onlyLegacy fallback, still supportedAccepted; the Sume CLI defaults to it
Both headersNot covered in the snapshot401 unauthorized; neither header wins

How do I end up sending both?

The Sume docs name the cause: gateways and fetch wrappers that add their own Authorization header on top of a client that already sends x-api-key. They advise stripping one rather than relying on a precedence rule. The 401 itself is covered in send only one.

What should I standardize on?

For a new Sume integration, use Authorization: Bearer $SUME_API_KEY to match the order Anthropic now shows, and remove x-api-key from any shared client or proxy that injects headers. Sume documents both as accepted, so this is a consistency choice, not a requirement.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume