API Key

An API key is a secret token, usually a random string of 32 to 64 characters like AIzaSyD-9tSrke72... or sk_live_4eC39H..., that an application includes with every request to an API. When the server sees the key, it looks it up in its database, finds the project it belongs to, and decides whether to serve the request.

The key answers one question: which application is calling? It does not answer who is the logged-in person. That distinction matters. A weather app that calls the OpenWeatherMap API uses one key for all of its users combined. The API has no idea which individual end user triggered the call, only that this app made it.

Keys are issued from a developer console. You sign up, create a project, and the platform generates a key you paste into your code or config. Stripe, Google Maps, OpenAI, SendGrid, and almost every paid API work this way.

On request, the client attaches the key. The common patterns are an HTTP header (Authorization: Bearer sk_live_... or x-api-key: ...), a query string parameter (?api_key=...), or a request body field. Headers are preferred because URLs get logged in server access logs, proxies, and browser history, leaking the key.

The server receives the key, hashes or looks it up against its store, and resolves it to an account, a set of permissions (scopes), and a quota. If the key is missing, unknown, revoked, or over its rate limit, the server returns 401 Unauthorized or 429 Too Many Requests. If valid, the request proceeds and the server increments that key's usage counter for billing and analytics.

Good platforms store only a hash of the key, not the raw value, the same way they store passwords. They show you the full key once at creation and never again. They also let you create multiple keys per project so you can rotate or revoke one without breaking everything, and restrict keys by IP address, referrer domain, or allowed API method.

The fundamental weakness is that a key is a bearer token. Anyone who has the string can use it. There is no challenge, no signature over the request body, no proof of identity beyond possession. If the key leaks, the holder is you as far as the API is concerned, until you revoke it.

Use API keys for server-to-server calls, usage metering, rate limiting per project, and identifying first-party or partner applications. They are simple, stateless on the client, and easy to generate and revoke. For a backend service calling Stripe or Twilio, a key is the right tool.

Do not use an API key as user authentication. It cannot tell users apart and it grants the same access to anyone holding it. For that you need OAuth tokens, JWTs, or sessions that identify and authorize a specific person. A common mistake is shipping a secret key inside a mobile app or frontend JavaScript bundle, where anyone can extract it with browser dev tools or by decompiling the app.

When a key must live in client code, use a restricted publishable key (Stripe calls these pk_, Google restricts Maps keys by referrer) that can only do safe, public operations, and keep the powerful secret key on your server. Always send keys over HTTPS, store them in environment variables or a secrets manager rather than committing them to Git, and rotate them on a schedule. GitHub and others now scan public repos for leaked keys and auto-notify providers like AWS to disable them.

Say you build a backend that generates email summaries using OpenAI. You create a key sk-proj-abc123 in the OpenAI dashboard and store it as the OPENAI_API_KEY environment variable on your server. Your code reads it and sends it as Authorization: Bearer sk-proj-abc123 with each chat completion request.

OpenAI's gateway resolves that key to your organization, checks you are under your spending limit and your requests-per-minute cap, runs the model, and adds the token cost to your monthly bill tied to that key. At month end you can look in the dashboard and see exactly how many requests and dollars that one key consumed.

If your server is compromised and the key leaks to GitHub, an attacker can run up thousands of dollars in charges in hours. That is why you would scope a separate key per service, set a hard usage limit, and revoke and regenerate the moment anything looks wrong. The key is your identity to the API, so it is treated like a password.