API keys

A password for your app

The simplest form of authentication is an API key. It's a long, random string that identifies your application. Think of it as a password, but for your app instead of a person.

When you sign up for a service like Google Maps or a weather API, they give you an API key. Every time your app makes a request, it includes that key so the server knows which app is calling.

Every service generates keys in its own format. Here are a few real examples:

e8a41c0f3b2d4a5e9f7c1b3d5a7e9f2c
AIzaSyB1hTfKaP3mVfG8xRz2nLwJqK9dE4cX7Yo
sk_live_4eC39HqLyjWDarjtT1zdp7dc

They all look different, but they do the same thing: uniquely identify who's making the request.

Where does the key go?

There are two common places where API keys are sent. You'll see both in documentation.

In a query parameter (the simplest approach). You just add the key to the URL:

This is how Google Maps, NewsAPI, and OpenWeatherMap do it. Simple: you paste the key right into the URL. You can even test it directly in your browser.

In a header (more secure, but needs a tool):

Headers are more secure because query parameters can end up in browser history, server logs, and shared URLs. Imagine accidentally pasting a URL with your API key into a Slack channel. With headers, the key stays hidden.

The catch: you can't set headers from a browser's address bar. When you type a URL in your browser and hit Enter, that sends a simple GET request with no custom headers. To add an Authorization header, you need a tool like Postman, or you need your app's code to do it. That's why query-parameter-based keys are easier to test: you just paste the URL and go.

The API documentation always tells you which method to use. You don't get to choose.

What the server sees

When your request arrives, the server extracts the API key and looks it up. Behind the scenes, there's a table that maps keys to apps:

The server checks: does this key exist? Is the plan active? Has the app hit its rate limit? If everything checks out, the request goes through. If the key is missing, invalid, or over its limit, the server rejects the request.

This is how services know who's calling even without a login screen. No username, no password. Just the key.

Real-world examples

Google Maps: every time you see a map embedded on a website, the developer's API key is included in the request. Google uses it to track usage and bill accordingly. Free tier: up to a certain number of map loads. Beyond that, you pay.

Stripe: when an app charges a credit card, the request includes a Stripe API key. The key determines which Stripe account the payment goes to. Stripe gives you two keys: a "test" key for development (no real charges) and a "live" key for production (real money).

Weather APIs: apps that show the forecast call a weather service with an API key. The free plan might give you 1,000 requests per day. Enough for a side project, not enough for a popular app.

The pattern is always the same: sign up, get a key, include it in your requests.

The golden rules of API keys

API keys are secrets. They need to be treated like passwords. A few rules that every developer knows (and that you should know too, as a PM):

Never put API keys in frontend code. If your key is in JavaScript that runs in the browser, anyone can open the page source and see it. This is like writing your password on a whiteboard. API keys belong on the server, where only your backend code can access them.

Never commit API keys to Git. Code repositories (even private ones) are not safe storage for secrets. If a developer accidentally pushes a key to GitHub, bots can find it within minutes. Companies use special tools called "secret managers" to store keys safely.

Rotate keys if they leak. If a key gets exposed, the fix is to generate a new one and delete the old one. Most services let you do this in their dashboard. It's like changing your password after a breach.

Use different keys for different environments. One key for testing, one for production. If the test key leaks, your real data stays safe.

When your engineering team says "we need to rotate the API key" or "we can't put this key in the frontend," this is what they mean. It's not paranoia. It's standard practice.

Key takeaways

• An API key is a secret string that identifies your app to a server
• Keys are sent in query parameters (simple, testable in a browser) or headers (more secure, needs a tool)
• You can't set headers from a browser's address bar. You need a tool like Postman or your app's code.
• The server matches the key to an app, checks the plan and limits, then responds
• API keys are secrets: never expose them in frontend code, never commit them to Git