API keys and auth headers
Most useful APIs aren't open to the world. The company needs to know who is asking, so they can track usage and bill you. They give you an key — a long string that identifies your account. You attach it to every request, usually in an header called Authorization, like the Bearer sk_live_... line above.
Treat an API key exactly like a password, because that's what it is. Anyone who has it can make requests as you — and run up your bill or read your data. This ties directly to the security chapter, and there is one rule that matters most:
- Never put an API key in code that ships to the browser. Anything in your is public — users can open dev tools and read it. The AI, asked to "call the API from the page," will cheerfully paste your secret key right there. Stop it. Secret keys belong on the server.
- Never a key to . Even if you delete it later, it lives forever in the history, and bots scan public repos for keys within minutes.
- Store keys in environment variables, not in the code itself — the same pattern the security chapter covers.
The key must travel from a safe place, never from the browser. Picture the two paths — one safe, one a leak:
SAFE ✓ LEAK ✗
┌──────────┐ key ┌──────────┐ ┌──────────┐ key ┌──────────┐
│ SERVER │ ─────▶ │ API │ │ BROWSER │ ────▶ │ API │
│ (your │ stays │ │ │ (anyone │ │ │
│ backend)│ hidden │ │ │ can │ │ │
└──────────┘ └──────────┘ │ read it)│ └──────────┘
key in env var └──────────┘
key in frontend = public
If you ever see a real key sitting in a diff, in a frontend file, or in a chat message, treat it as already leaked: rotate it (generate a new one, disable the old one) immediately.