What 401 actually means

"I don't know who you are." That's different from 403, which means "I know who you are and you're not allowed."

If you're getting 401, your credentials aren't arriving, aren't valid, or aren't in the form the server expects.

Work through it

Is the header actually being sent? Devtools, Network tab, click the request, look at Request Headers. Not what your code intends to send — what was sent. This resolves it more often than anything else.

Is the format right? Authorization: Bearer <token> — with the word Bearer, one space, no quotes, no newline. A trailing newline from reading a token out of a file is a classic.

Is the token expired? Access tokens are often short-lived. Decode it, or just request a fresh one and see.

Right key, wrong environment? Test keys against live endpoints, or the reverse. Every provider does this and everyone gets caught by it.

A redirect stripping the header? If your request is redirected — http to https, or a trailing slash — many clients drop the Authorization header on the redirect. Call the final URL directly.

A preflight arriving without credentials? In a browser, the OPTIONS request carries no auth. If your middleware rejects it, you see a CORS error or a 401 for a request you never made.

auth-401.txt
Calling <API> returns 401. Here's my request code: <paste>
Here's what the Network tab shows was actually sent: <paste headers,
with the token redacted>

Check: is the header present and correctly formatted? Is there a
redirect? Is this a preflight? Is the token in the right environment?

Then show me a minimal curl command that proves whether the credential
itself works, independent of my code.

Isolate the credential

Get it working in curl first. If curl works and your code doesn't, the problem is your code. If curl fails too, the problem is the credential or the account. That single split saves a great deal of time.

Never paste a real token into a chat. Redact the middle. The length and the prefix are all anyone needs to diagnose the format.