My API key isn't working — a 3-cause checklist that catches everyone

You got an API key, pasted it in, ran the code — and back comes 401 Unauthorized or invalid API key. The key is right there in front of you, looks correct. And the service says "never heard of it."

Good news: there are almost always just three causes, and all of them are mundane. Let's go through them top to bottom — from the most common. In 9 cases out of 10 it's fixed at step one.

Cause 1 (most common): the key didn't load, or has a typo

Most of the time the problem isn't the key but how it reached your code. A stray leading space, accidental quotes, an invisible line break from copying — and the service sees a different key. Or you fixed the key in your .env file, but the app still holds the old value in memory.

How to check. Don't print the whole key (it's a secret), but print its length and a couple of first/last characters: do they match what's in the service panel? Often you'll spot the extra space or that an empty string got substituted.

How to fix. Recreate the environment variable cleanly — no spaces, no quotes around the value. Then restart the app or server: variables are read at startup, they don't update on the fly. Another common trap is mixing up the test and live key (test vs live): make sure you grabbed the right one.

Cause 2: the key is sent to the wrong place

The key is correct, but you're putting it in the wrong spot or the wrong shape. One service expects it in the header Authorization: Bearer YOUR_KEY, another in x-api-key: YOUR_KEY, a third as a parameter in the URL. Mix up the format and the service doesn't recognize you, even though the key is right.

People especially often forget the word Bearer before the key, or put the key in the request URL instead of a header.

How to check. Open the service docs, the Authentication section: it shows verbatim which header and which format to send the key in. Compare it to your request letter by letter.

How to fix. The most reliable path is to use the service's official SDK: it puts the key in the right header for you, and this cause disappears entirely. No SDK? Make your header exactly match the docs.

Cause 3: the key has a problem on the service side

Sometimes the key is correct and sent correctly, but it's "dead" itself: not activated, revoked, out of balance, the needed product isn't enabled, or you hit the request limit (then the code is 429, not 401).

How to check. Open the service panel and find your key. Its status is there: is it active, which project it's tied to, is there a balance, has it expired. While you're there, check the needed service is enabled for that key.

How to fix. Activate the key, top up the balance, enable the right product — the status tells you which. If the key is revoked or expired, just issue a new one and swap it in (don't forget to restart the app, see cause 1).

I accidentally committed a key to GitHub — what do I do?

Treat it as compromised, even if the repo is private. Immediately revoke that key in the service panel and issue a new one. Deleting the commit isn't enough — the key may already be in someone else's hands. Going forward, keep keys only in .env and store them safely.

The key is in .env but isn't read — why?

Run a short checklist: is the .env file in the project root? Does the variable name in the file exactly match what the code expects (case matters)? Was the server restarted after the edit? And did a stray space or quote swap the value? These four questions close almost every "isn't read."