What is an API key?
An API key is a unique string of characters that identifies the application or person calling an API (the interface one program uses to talk to another). When your software sends a request, it includes the key, and the service on the other end checks it before answering. The key tells the service who is asking, whether they are allowed, and how much they can do.
You will see keys when you connect to a service like an email provider, a payment gateway, or an AI model. They usually look like a long line of letters and numbers, for example sk_live_4eC39H....
In plain words
Think of an API key as the membership card you show at the door. The bouncer does not need to know your life story. They glance at the card, see you are a paying member, and let you in. The service does the same: the key is your card, and every request flashes it to prove you belong.
How it works
The flow is short and happens on every single request:
- You get a key. You sign up for a service, open its dashboard, and generate a key. The service stores a copy and links it to your account.
- Your app sends it. Each request to the API carries the key, usually in a header such as
Authorization: Bearer <your-key>. - The service checks it. It matches the key against its records, confirms the account is active, and applies your limits and permissions.
- You get an answer, or a refusal. A valid key returns the data. A missing, wrong, or revoked key returns an error, often
401 Unauthorized.
Behind that simple exchange, the key also lets the service count your usage, bill you correctly, and shut off access the moment something looks wrong.
Security best practices
A key is a credential. Anyone who holds it can act as you and run up your bill, so treat it like a password.
- Keep keys out of your code. Store them in environment variables or a secrets manager, never hardcoded in the app or committed to Git.
- Use separate keys per purpose. A key for testing, a key for production, a key per service. If one leaks, you revoke only that one.
- Rotate keys on a schedule. Replace them every few months and immediately after anyone with access leaves the team.
- Limit what each key can do. Many services let you scope a key to specific actions or set a spending cap. Grant the least access the job needs.
- Revoke fast. If a key appears in a public repo, a log, or a screenshot, delete it and issue a new one. A leaked key does not fix itself.
Common pitfalls
- A key is identity, not real authentication. It says who is calling, but on its own it does not verify a logged-in user. For user-level access, pair it with proper auth such as OAuth.
- Keys leak through the front end. A key shipped in browser or mobile code is visible to anyone who looks. Call sensitive APIs from your own backend instead.
- Hardcoded keys end up in Git history. Even after you delete the line, the key lives on in old commits. Rotate it, do not just remove it.
- No limits means a big surprise bill. Without a usage cap, a leaked or buggy key can drain your budget before you notice. Set caps and alerts from day one.
Related articles:
- What is an API? - The interface that lets one program talk to another, explained without the jargon.
- SDK vs API: understanding the distinction - What each one does and when you reach for which.
- MCP under the microscope: how AI agents talk to tools - How AI agents connect to APIs and the risks that come with it.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.