API keys explained

What is an API key?

When your app talks to another service — a payment provider, an email sender, a model provider — that service needs to know who is asking. The key is the answer. It travels with the request, usually in a header, and the service looks it up to decide whether the request is allowed and whose account to charge.

fetch("https://api.example.com/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.EXAMPLE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ to: "someone@example.com" }),
});

Note where the key comes from: an environment variable read on the server. It is never typed into the file and never sent to the browser.

Why are some keys safe to expose and others are not?

Services often issue two kinds of key. A publishable or anonymous key is designed to be visible: on its own it can only do things the service considers safe for anyone, and the real protection lives in server-side rules. A secret key is designed to never leave a server: it can act with your full account permissions.

A publishable key being visible is not a breach. A secret key being visible is — treat it as compromised and rotate it, do not just delete the line.

Where should a key actually live?

1. 1Store it as an environment variable in whatever runs your server code.
2. 2Read it inside the function that makes the request, not at the top of a shared file.
3. 3Keep it out of version control — no keys in committed files, ever.
4. 4Set it separately for each environment: local, preview, production.
5. 5Give it the narrowest permissions the service offers.

What does a leaked key actually cost?

• Someone else spends your quota or your money, sometimes at scale within hours.
• The service rate-limits or suspends your account because of traffic you did not send.
• With a secret key, an attacker can read or change data on your behalf, not just use the service.

Rotation is the only real fix. Deleting the key from a file does not help, because the old value is still in your Git history and in anything that cached the page.

What does AI often get wrong here?

Generated code frequently puts a working request in a component because that is the shortest path to something that runs. If that component renders in the browser, the key ships to every visitor. The code is not wrong in the sense of failing — it works perfectly, which is exactly why it is easy to miss.

The habit worth building: every time you see a key used, ask where that code runs. If the answer is 'in the browser', move the call to the server.