The Key Is a Password
An hour after the key works, a colleague asks Vera how she pulled the rides. She takes a screenshot of her terminal to show him — the command, the header, the beautiful 200 — and her thumb is over the send button before she stops. The whole key is in that image, at readable size. She deletes it and pastes a description instead. This page exists because almost everybody nearly does that, and a fair number do not stop.
Here is the identity to fix in place: a key is a password with a longer name. Whoever holds it is Vera as far as Tandem is concerned — her quota, her permissions, her account, her blame. There is no second factor, no code sent to her phone, no face to check. The string is the whole proof. You already have good password instincts; this page's only real job is to make you apply them to something that does not look like a password.
What a Leak Actually Looks Like
Leaks are almost never dramatic. They are helpful. Somebody screenshots a working terminal to prove a point. Somebody pastes a full curl command into a ticket so support can reproduce it. Somebody drops the key into a shared document so the team stops asking. Every one of those is a person being useful, and every one of them copies a password into a place with no lock on it.
The subtlest path is the one the last page flagged. When an API accepts the key as a query parameter — part of the URL after the question mark — the key stops being a header and becomes part of an address. Addresses get logged. Web servers log them, proxies log them, analytics tools log them, browser history keeps them, and error reports quote them back at you in full. A key in a header stays out of the address logs that every layer keeps by default. A key in a URL is written down by half a dozen systems that were never told it was a secret.
Where a Key Should Live
For someone at Vera's level — no code, no deployment, one laptop — the rules are short. Keep the key in a password manager, in the same vault as everything else that would ruin your week. Not in a note, not in an email you can search for later, not in a chat message to yourself, and not in the spreadsheet that holds the Thursday report.
The second rule is a habit rather than a place, and it is the one that matters most in practice. Redact before you ask for help. When you paste a curl command into a ticket, a message, or an email, replace the key with something visibly fake — tnd_live_XXX is the convention this book uses. Jonas genuinely does not want to see the real one. He can look up Vera's account from his side; a support engineer never needs your secret to help you, and being handed it makes his day worse, not better.
Rotation: the Fix That Always Works
Rotation means asking the provider for a new key so the old one stops working. It is the answer to every version of the question "I think my key got out." Not "did anyone actually see it", not "how bad is it" — assume it is gone, rotate, move on. The decision takes ten seconds and the doubt would take a week.
It helps to know that providers want you to do this. Rotation is usually a button in the partner dashboard, and most providers will let a new key and an old key work at the same time for a while precisely so nothing breaks in the changeover. Rotation is routine hygiene, like changing a lock when you lose a spare. It is not a confession and nobody thinks less of you for it.
Where the Blast Radius Ends
Not all keys cost the same when they escape. Vera's read-only key, in a stranger's hands, exposes ride records the public never sees and burns her quota. Uncomfortable — but bounded. A key that can create rides, cancel reservations, or move money is a different object entirely, and the difference is nothing but the scope attached to it.
That is why "ask for the minimum permissions you actually need" is advice aimed at you, not only at administrators. Scopes are the size of the hole in the wall. When Vera asks Jonas for the two read scopes and not for write access she will never use, she is not being modest — she is deciding, in advance, how bad the worst day can get.
- "It is only an API key, not a real credential." It is the realest credential in this book. No second factor, no password reset flow, no human check — the string alone is the proof, and it carries quota, data access, and sometimes money.
- "I shared it in a private channel, so it is fine." Private channels get exported, forwarded, archived, and occasionally breached. A secret has to be treated as living in the least private room it has ever entered, and the cure for doubt is rotation rather than hope.
- "Rotating the key will break everything." It breaks exactly the places that were using the old key, which is the inventory you wanted anyway. Overlapping keys exist so the changeover can be calm instead of a fire drill.
- "A key in the URL is the same as a key in a header." Not in practice. URLs are logged by servers, proxies, analytics, and browser history, and every one of those logs keeps it. (Headers can still escape — verbose curl output and browser network exports carry them, so redact those too.)
- A leaked key is the most common real API incident a beginner will ever cause or witness. Ten minutes here is what stops it, and the habit stays.
- The redact-before-asking habit lets you use Chapter 7's escalation checklist freely. You get to send the full reproduction that makes support fast, without ever creating a second incident while reporting the first.
Knowledge Check
Vera wants Jonas to reproduce a failing request. What does she send him?
- A screenshot of her terminal showing the whole working command
- The curl command with the key replaced by tnd_live_XXX
- The full command in a private channel, since only Jonas reads it
- A written description of the request with no command attached
Vera is not sure whether her key was exposed. What should she do?
- Rotate it, because the doubt costs more than the rotation
- Watch her quota for a week and rotate only if it looks strange
- Nothing, since an unused key eventually stops working by itself
- Ask Jonas to check whether anyone else has used her key
Why is a key in a query string worse than the same key in a header?
- Query strings travel unencrypted while headers are protected
- URLs get logged by servers, proxies, and browser history
- Query strings are too short to hold a full-length API key
- Servers cannot read a credential correctly from a query string
Why does the scope on a key change how bad a leak is?
- A narrower scope lets the provider revoke the key faster
- The scope decides what a stranger holding it can actually do
- Keys with narrow scopes are harder for a stranger to guess
- A wide scope makes the leak easier for the provider to notice
You got correct