What Is an API Key? Authentication Basics, Explained

The first time I built something that talked to another company's service, I signed up, clicked around a dashboard, and was handed a long, ugly string of letters and numbers. Something like sk_live_4eC39HqLyjWDarjtT1zdp7dc. No instructions. No explanation. Just "here is your API key, paste it into your app."

I had no idea what it was, where to put it, or why it mattered. So I did what a lot of beginners do: I pasted it directly into my code, pushed it to a public GitHub repository, and went to bed. By morning, a stranger had used my key and run up a small bill on my account.

That string was an API key, and I want to spare you my mistake. So let me explain, calmly, what an API key actually is, why services hand them out, and the handful of habits that keep yours safe.

A membership card for software

If you've read my piece on how APIs actually work, you know an API is a way for two programs to talk: your app sends a request, a service sends back a response. But there's a missing piece in that picture. When your app knocks on the door of, say, a weather service, how does the weather service know who is knocking?

That's the job of an API key. An API key is a secret string of characters that identifies your app to a service and proves you're allowed to use it. It travels along with your request, quietly, like an ID you slide across a counter.

The analogy I keep coming back to is a membership card. Think of a gym. When you walk in, you tap your card on the reader. The card doesn't do anything by itself, it's just a piece of plastic with a number on it. But that number is tied to your account. The reader checks it, sees you're a paid member, and the gate opens. If you forgot your card, you don't get in, no matter how much you insist you're a member.

A hotel key card works the same way, and it adds a detail I like: your key only opens your room, not every door in the building. Hold that thought, because it matters later.

An API key is that card. Your app presents it, the service checks it against its records, and if everything matches, the request goes through.

Why services bother with keys

You might wonder why a service can't just let everyone in freely. A few real reasons:

Tracking usage. Every time your key is used, the service logs it. That's how they know app A made ten thousand requests yesterday and app B made twelve. Without keys, every request would be an anonymous stranger.

Rate-limiting. Most services cap how often you can call them, say, a hundred requests per minute. The key is how they count your requests specifically, so one badly-written app can't overwhelm the whole system.

Billing. Many APIs are paid. The key ties your usage to your account so they can charge you the right amount. This is exactly why my leaked key cost me money: the service happily billed my account for the stranger's requests, because the requests carried my key.

Security and accountability. If a key starts behaving badly, the service can shut off that one key without affecting anyone else. It's a clean off-switch.

Authentication vs. authorization

Here are two words that sound almost identical and get mixed up constantly. Getting them straight will make everything else click.

Authentication answers the question: who are you? It's the act of proving your identity. Showing your gym card at the door is authentication. The reader confirms you are who your account says you are.

Authorization answers a different question: what are you allowed to do? Your gym card might get you into the building (authenticated) but not into the private trainers' lounge (not authorized for that area). The hotel key card that opens your room but not your neighbour's is doing authorization.

An API key often handles both. It authenticates you (this request is from Happyness's app) and it carries your permissions (this account can read weather data but can't, say, delete other users). Keeping these two ideas separate in your head helps enormously when something goes wrong. "Access denied" because the service didn't recognise your key is an authentication problem. "Access denied" because your key isn't allowed to touch that particular thing is an authorization problem. Different cause, different fix.

A quick word on tokens and OAuth

API keys are the simplest form of authentication, but they're not the only one, and you'll bump into the alternatives soon enough.

A token is like an API key with an expiry date stamped on it. Instead of one permanent key you use forever, the service gives you a token that works for, say, an hour, then you have to get a fresh one. Short-lived tokens are safer: if one leaks, it's useless tomorrow.

OAuth is the system behind those "Sign in with Google" buttons. When an app asks to use your Google account, you're not handing it your password or a permanent key. Google authenticates you, asks if you consent, and then issues the app a limited token on your behalf. The app never sees your actual credentials. It's a polite, revocable handshake, and it's how you grant one service limited access to another without giving away the keys to your whole house.

You don't need to master OAuth today. Just know that "API key" sits at the simple end of a spectrum, and tokens and OAuth are what you graduate to when you need finer control.

The part that actually matters: keeping your key secret

Everything above is context. This is the section I wish someone had sat me down for.

An API key is a secret. Treat it like a password, because functionally, that's what it is. Anyone who has your key can pretend to be you. Here's how to not repeat my night.

Never commit a key to GitHub. This is the mistake that cost me. The moment your key lands in a public repository, bots scan it within minutes, sometimes seconds. If you're fuzzy on what committing and repositories even mean, my explainer on Git and GitHub will fill the gap. The short version: assume anything you push publicly is read instantly by strangers.

Use environment variables. Instead of writing the key directly in your code, you store it in your computer's environment (often in a file named .env that you deliberately keep out of Git) and your code reads it from there. Your code says "fetch the key named WEATHER_API_KEY" without the actual key ever appearing in a file you'd share.

Restrict the key's scope. Remember the hotel key that only opens your room? Many services let you do the same: create a key that can only read data, or only reach certain endpoints. If that limited key leaks, the damage is contained.

Never put secret keys in front-end code. Anything that runs in a user's browser can be read by that user. View-source, open the network tab, and there's your key. Secret keys belong on a server you control, never shipped to the browser. (Some services issue special publishable keys designed to be public, but those are deliberately limited. Know which kind you're holding.)

Rotate leaked keys immediately. If a key is exposed, don't try to clean it up quietly. Go to the dashboard, delete the old key, generate a new one. The old key becomes worthless the instant you revoke it. This is the off-switch I mentioned earlier, and it's the only real cure.

What to take away

An API key is a secret string that tells a service who you are and what you're allowed to do, the membership card your app taps on the way in. Services use keys to track, limit, bill, and secure access. Authentication is who you are; authorization is what you can do. Tokens and OAuth are the more sophisticated cousins you'll meet later.

And the rule that outweighs all the others: a key is a secret. Keep it out of your code, out of your browser, out of public repositories, and rotate it the moment it slips.

Frequently asked questions

Is an API key the same as a password?

Functionally, very nearly. Both are secrets that prove identity and grant access, and both should be guarded the same way. The difference is that a password is usually typed by a human to log in, while an API key is used by software to authenticate itself automatically. Anyone holding your key can act as your app, so treat it with the same care you'd give a password.

What happens if someone steals my API key?

They can make requests as if they were you, which may run up charges on your account, hit your rate limits, or access data your key is permitted to reach. The fix is immediate: revoke the stolen key in the service's dashboard and generate a new one. Once revoked, the old key stops working instantly, so the thief is locked out.

Where should I store my API key?

In an environment variable, typically kept in a .env file that you deliberately exclude from Git, or in your hosting provider's secrets manager. Never hard-code it directly into source files, and never put a secret key in code that runs in the browser, since users can read anything sent to their browser.

Why do some services give me two keys, a public one and a secret one?

The publishable (public) key is safe to include in front-end code and is deliberately limited, often only able to identify your project. The secret key has real power and must stay on your server, hidden from users. Always check the documentation to know which kind you're holding before you decide where it can go.

Do I need to understand OAuth to use API keys?

No. API keys are the simplest form of authentication and are enough for most beginner projects. OAuth and short-lived tokens become useful when you need users to grant your app limited access to their own accounts, or when you want credentials that expire automatically. Start with keys; reach for OAuth when a project genuinely calls for it.

Further reading on this site

• How APIs Actually Work — the bigger picture your key fits into
• What Are Git and GitHub? — so you never commit a secret by accident
• Browse Technology — more calm explainers like this one

If this helped, subscribe to the newsletter for new plain-English explainers as they land.