API key

API key is a secret string that a client sends with every request so the server can tell which application or account is calling. API stands for Application Programming Interface. You get one from a provider's dashboard, and you usually put it in an HTTP header. A key identifies a client and is easy to rotate, but it is not a login for a person and it does not prove who the end user is.

How it works

The provider generates a long random value and ties it to an account, a plan and a set of permissions. When a request arrives, the server looks the key up, checks that it is active and allowed to call that endpoint, and then applies rate limits or billing for that account.

• Where to send it: an HTTP header is the usual place. Stripe accepts Authorization: Bearer <key>, and the Claude API also accepts an x-api-key header. Each provider defines its own header, not one standard.
• Where not to send it: a query string. OWASP's REST guidance says API keys should not appear in the URL, because web server logs capture it. A Referer header can also carry the full URL on same-origin requests.
• Transport: always HTTPS. Over plain HTTP anyone on the path can read the key.
• Format: providers choose their own. Stripe marks secret keys with sk_ and publishable keys with pk_. This page's example uses sk_live_ plus 48 hex characters, 56 characters in total.

The script below builds a key of that shape from 24 random bytes. It then starts a local test server and sends the same test key twice, once in a header and once in the URL.

const crypto = require("crypto");
const http = require("http");
const key = "sk_live_" + crypto.randomBytes(24).toString("hex");
console.log(key.length, /^sk_live_[0-9a-f]{48}$/.test(key));
const server = http.createServer((req, res) => {
  console.log(req.method, req.url, "| auth:", req.headers.authorization ?? "-");
  res.end();
}).listen(0, async () => {
  const url = "http://localhost:" + server.address().port + "/v1/items";
  await fetch(url, { headers: { Authorization: "Bearer sk_test_EXAMPLE" } });
  await fetch(url + "?api_key=sk_test_EXAMPLE"); // avoid
  server.close();
});

Output from Node.js 22:

56 true
GET /v1/items | auth: Bearer sk_test_EXAMPLE
GET /v1/items?api_key=sk_test_EXAMPLE | auth: -

In the first call the key stays in the Authorization header and the request URL is clean. In the second the key is part of the URL, which is what access logs record.

API key vs OAuth 2.0 token

An API key identifies the calling application, while an OAuth 2.0 access token represents a user's delegated permission and normally expires. Use OAuth 2.0 when your app acts on behalf of other people. A key is fine for server-to-server calls where you own both sides. A JWT is a token format and is sometimes used as the access token, so it is not an alternative to a key in the same sense.

Common pitfalls

• Committing keys to Git: a key in a repository stays in history after you delete the file. Revoke it immediately and rotate it, then load keys from environment variables or a secrets manager.
• Shipping a secret key in browser or mobile code: anyone can read it from the bundle or network tab. Keep secret keys on a server, and use restricted, publishable keys for client code if the provider offers them.
• Putting the key in a query string: it lands in server logs. Move it to a header.
• One key for everything: a single shared key cannot be revoked without breaking every caller. Issue one key per client, with the narrowest scope the provider allows.
• Never rotating: a leaked key works until someone revokes it. Set a rotation schedule and support two active keys during the switch.
• Using a key as user authentication: a key says which app is calling, not which person. Add a real login for user-facing actions.

Related terms

• OAuth 2.0 — delegated authorization with expiring tokens, the usual alternative for user data.
• JWT — a signed token format often used as an access token.
• HMAC — signing requests with a shared secret instead of sending the secret itself.
• HTTPS — the transport that keeps the key from being read in transit.
• HTTP — the protocol whose headers usually carry the key.
• Webhook — callbacks that often use a shared secret to prove they came from the provider.

See also

• Cheatsheet: HTTP Headers Reference — Authorization and other request headers.