Copy the headers from your browser's network tab or from curl -v and paste them here. The credential values are masked in the output while the analysis uses the full value, so the result is safe to screenshot.
What it finds
Duplicated scheme — Bearer Bearer eyJ…. A client prefixed a token that already had its prefix. Produces a 401 whose message never mentions it.
Quotes in the value — copying "eyJ…" from a JSON config sends the quotes as part of the credential.
Unexpanded variables — Bearer ${API_TOKEN} or Bearer $(cat token). The shell or template never substituted. Detected explicitly because it is common and the resulting error is opaque.
Trailing whitespace or a newline — from copying out of a wrapped terminal.
Expired JWT — the payload is decoded and exp compared against now, so you get "expired 40 minutes ago" instead of a bare 401.
Conflicting credentials — both Authorization and X-API-Key present. Most gateways use one and silently ignore the other, and which one is rarely documented.
Cookie alongside Authorization — if the API accepts cookie authentication, it may be exposed to CSRF where the header path is not.
GraphQL differs in one important way
GraphQL returns 200 OK for authorisation failures, with the problem in an errors array in the body:
{
"data": { "viewer": null },
"errors": [{
"message": "Not authorized",
"extensions": { "code": "UNAUTHENTICATED" }
}]
}A client that checks only response.ok will treat this as success and then fail confusingly on null data. Always check the errors array.
Field-level authorisation also means a single request can be partly authorised: data populated for permitted fields, errors listing the denied ones. That is correct GraphQL behaviour and it surprises clients written against REST.
Browser requests expose the credential
If the headers include an Origin, the request came from a browser — which means the credential is visible to every user of that page, in the network tab and in the bundle. Confirm the key is one that is meant to be public. If it is not, proxy the call through your backend.
Frequently asked questions
Where do I get the headers?
Browser devtools → Network → select the request → Request Headers → "view source" for the raw text. Or run curl with -v, which prints the request headers with > prefixes.
My header looks correct but I still get 401.
Then the header is not the problem — the credential is. Check the environment (test key against production is the most common cause), whether the key was revoked, and whether it has the scope this endpoint needs. The authentication sandbox walks the whole decision sequence.