1. What an API key actually is
An API key is a long, unique string — usually 20 to 60 characters of letters and
numbers, sometimes with a recognisable prefix like sk_live_ or
AIza — that identifies your application to an API provider.
It's less like a password (which proves who you are) and more like a
barcode: it tells the server which account to bill, which rate limit to apply, and
whether the request is allowed at all.
Think of it like a keycard for a building with many tenants. The card doesn't prove you're a specific person — it proves you belong to a specific company, and it determines which floors you can access. Lose the card, and whoever finds it can walk in as your company until you deactivate it.
2. How you get one
The process is nearly identical across almost every API provider:
- Create an account on the provider's developer portal (usually free for a limited tier).
- Create a "project" or "app" — most providers key-scope by project rather than by account, so one login can hold several separate keys for separate apps.
- Generate the key — a button in the dashboard, instant, no approval wait for most free tiers.
- Copy it somewhere safe immediately — many providers show the full key exactly once and only display a masked version (
sk_live_••••1234) afterward.
On our catalog, every API page's Authentication section tells you which of these flows applies, and links to the provider's signup page directly.
3. Where the key goes in a request
There are three common places a key travels with a request, and providers don't agree on which one to use — you have to check each API's docs (or its page in our catalog):
| Method | What it looks like | Notes |
|---|---|---|
| Authorization header | Authorization: Bearer sk_live_abc123 |
Most common for modern APIs. Not visible in server logs or browser history — the safest default. |
| Custom header | X-API-Key: abc123 |
Functionally identical to the above, just a different header name. Check the docs for the exact name. |
| Query parameter | ?api_key=abc123 |
Simplest to test in a browser, but the key ends up in server access logs, browser history, and any URL you accidentally share or screenshot. Avoid where a header alternative exists. |
4. API key vs. OAuth vs. Basic Auth
An API key is the simplest of several authentication styles you'll run into. Knowing the difference helps you understand why an API asks for what it asks for:
A useful rule of thumb: if the API is acting as your app (fetching public weather data, looking up a VIN), expect an API key. If it's acting on behalf of one of your users (posting to their account, reading their private data), expect OAuth.
5. Keeping your key safe
A leaked API key is one of the most common — and most avoidable — security incidents in software. Automated bots continuously scan public GitHub repositories for key-shaped strings within seconds of a commit going public, specifically looking for exactly this mistake.
Never commit it to source control
Put keys in environment variables, not in your code:
Add your .env file to .gitignore before your first
commit, not after — once a secret is in git history, deleting the file later doesn't
remove it from that history.
Scope the key to what it actually needs
Many providers let you restrict a key to specific endpoints, specific HTTP methods (read-only vs. read-write), or specific domains/IP addresses it's allowed to be called from. A key that can only read weather data can't do much damage if it leaks; a key that can also issue refunds is a very different risk. Scope down by default.
Use different keys for different environments
A separate key for local development, staging, and production means a key accidentally pasted into a bug report or a Slack message during development can be revoked without taking your live application down.
6. If your key leaks anyway
- 1. Revoke or rotate the key immediately in the provider's dashboard — this stops the bleeding before you investigate anything else.
- 2. Issue a new key and update it everywhere the old one was used.
- 3. Check the provider's usage/billing dashboard for a spike in requests during the exposure window — that tells you whether it was actually exploited.
- 4. Remove it from git history if it was committed, using a tool like
git filter-repo— a normal commit reverting the file is not enough, since the key is still readable in earlier commits.
Rotating first and investigating second is the right order even if you're not sure the leak was ever seen by anyone else — a new key costs you a few minutes; a stolen one on a paid tier can cost real money before you notice.
Ready to get your first key?
Every API in our catalog lists its auth type up front, so you know exactly what you're signing up for before you start.