API Key
The ID you present when you call an API
- An API key is a long string sent along with a call. That string is what stands in for "you."
- Unlike a password, it doesn't come with a name attached. Whoever holds the key gets treated as the owner.
- Each key can be set up with its own doors and its own limit on how much it can be used.
- If it leaks, someone else can act under your name, and the bill and the record land on you.
- If it leaks, don't try to cover it up — cutting it off and getting a new one is the only real fix.
Contents
1The analogy
An office badge is one card. Tap it at the gate and the door opens; without it, the door stays shut. The card is what opens the door, not the person. Whoever is holding it, the gate only looks at the card.
Cards open different doors, too. Some reach only the office, others go all the way to the server room. A visitor's badge locks itself out automatically by evening.
Every pass gets logged, too — which door, at what time.
That's why losing a badge is a problem. Whoever picks it up opens doors under your name, and the record piles up as yours. There's only one thing to do about it: deactivate that card and get a new one.
An API key is that badge.
2In detail
It checks the badge, not your name
An API key is a long string of letters and numbers with no meaning of its own. Send this string along with a call, and the receiving end looks it up on a list, treats it as belonging to the owner on file, and does the work.
What matters here is that there's no username and password sent alongside it. The key alone is the whole story. Whoever ends up holding it can act as the owner with no extra steps. A key is more of an ID card than a lock, and that ID card has no photo on it.
It's also not something a person memorizes and types in. It sits inside a program and gets attached automatically to every call, which is exactly why it tends to sit around in places nobody notices for a long time.
Different badges open different doors
Making one key that can do absolutely everything is risky. So keys get scoped when they're created — a read-only key, a key limited to certain features, a key capped at a certain amount per day.
Splitting keys up by purpose keeps an incident from spreading. If a key made for testing leaks, only the testing door opens. It's also easier to tell which key leaked, since each one builds up its own separate usage log.
Setting an expiration helps too. Just like a visitor's badge locking itself out by evening, putting an expiration date on a key cuts down on ones that get forgotten and sit alive for years.
Where not to leave it
The most common incident is writing a key directly into a program and then publishing that whole program somewhere public. A key sitting in a public place can get scraped up within minutes — automated scanners find it before a person ever would.
Putting one into code that runs in the browser is risky too. Not showing up on screen doesn't mean it's hidden. Anything that made it down to the browser is something anyone can open and read. A key belongs on a server nobody can reach by hand, with anything on screen calling through that server instead.
Pasting it into a chat message, leaving it up on a screen you're sharing, or letting it show up in a screenshot are the same kind of incident. Write it into a document or a note, and the moment that document gets passed along, the key goes with it.
If it leaks
A leaked key can't be patched. You don't paint over a lost badge. What to do is fixed: cut off that key, get a new one, and swap it in everywhere the old one was used.
After that, check the log. It shows when unfamiliar activity started and how much got called in the meantime. A sudden burst of use during a time you weren't active is a sign someone else was using it. On a service that bills by usage, the longer it takes to notice, the bigger the loss.
There's also something worth setting up ahead of time: a cap on how much can be used. Put a ceiling on it, and even a leak stops doing damage past that line. Noticing fast and cutting it off fast is more realistic than trying to prevent every leak.
3More precisely
An API key is the simplest way to handle proving who you are and what you're allowed to do in one step. Simple comes with a weak point, too — one string is the entire identity, so once it leaks there's no way to walk it back. That's why more careful setups reach for a short-lived pass that expires quickly, or layer in a check on where the call is coming from.
The badge comparison breaks down in one place. Lose a badge and you notice right away — it's gone from your hand. A key can get copied while the original stays right where it was, so a leak can go unnoticed for a while. A badge also belongs to one person, but a key often gets shared across several programs, so cutting off one key can stop several things at once — which is exactly why making a separate key for each purpose gets recommended. This is also why the place that issues a key usually won't show you the original value again: it's shown once, at the moment it's created, and after that you're expected to get a new one if you lose it.
4Try it yourself
5Common misconceptions
It's easy to think a key works like a password, but actually there's no name attached to it — the string is the whole story, so whoever holds it is treated as the owner.
It's easy to think it's fine in browser-side code as long as it isn't visible on screen, but actually anything that made it down to the browser can be opened and read by anyone.
It's easy to think being careful is enough once it's leaked, but actually cutting it off and getting a new one is the only way back.
7One-line summary
In shortAn API key is the badge that stands in for you at the door, and where you keep it and how fast you cut it off if it leaks are almost the whole story.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02