What Is an API Key?

An API key is a string an application sends with each request to identify which client or project is calling an API. It lets the service recognise the caller, count usage, and apply rules such as quotas and rate limits.

Keys look ordinary but carry real authority. If someone copies your key, they can usually make calls as you. This article explains what an API key actually does, how it differs from authentication, where to store one safely, and the mistakes that lead to leaked credentials.

What an API key actually is

At its simplest, an API key is a long, hard-to-guess string the provider generates for you, for example sk_live_4eC39HqLyjWDarjtT1zdp7dc. Some providers prefix keys so you can tell a test key from a live one, or so leak-detection scanners can spot the format.

The server stores a record (often a hash) of every issued key alongside the account or project it belongs to. When a request arrives carrying that key, the server looks it up, confirms it is active, and treats the call as coming from the associated account.

A key is best understood as a shared secret: both you and the provider know the same value, and possession of it is treated as proof of identity. That is also its weakness, which we return to below.

How API keys work in a request

You attach the key to each HTTP request. The three common placements are:

• An HTTP header — the most common and most secure of the three, for example Authorization: Bearer YOUR_KEY or a custom header like X-API-Key: YOUR_KEY.
• A query-string parameter — such as ?api_key=YOUR_KEY. This works but is discouraged, because URLs are frequently written to server logs, browser history, and proxy caches.
• A request body field — used by some older or form-based APIs.

A header-based request looks like this:

GET /v1/customers HTTP/1.1
Host: api.example.com
Authorization: Bearer sk_live_4eC39HqLyjWDarjtT1zdp7dc

The server reads the key, validates it, then returns the data or a 401 Unauthorized / 403 Forbidden response if the key is missing, revoked, or not permitted to perform that action.

Identification is not the same as authentication

This is the single most misunderstood point. An API key primarily identifies a project so the provider knows whom to bill and how to throttle. It is a weaker statement than full authentication, which proves that a specific verified user is present.

The practical consequence: a plain API key is fine for telling callers apart and metering usage, but it is not a strong substitute for user login. Anyone who holds the string can use it, there is no second factor, and a key usually does not expire on its own. For per-user data or sensitive operations, providers layer on stronger schemes.

API keys versus token-based auth

It helps to compare the common approaches side by side:

These are not mutually exclusive. Many services use a key to identify the calling application and a short-lived token to authenticate the end user within it. The OAuth 2.0 versus JWT comparison covers when delegated access is the right model rather than a static key.

Why API keys matter

Keys exist because providers must answer practical questions on every request: Who is this? Are they allowed? Have they exceeded their plan? A key is a stable handle for several functions at once:

• Usage accounting and billing — every call ties back to a project, so the provider can meter and invoice it.
• Rate limiting and quotas — limits are enforced per key, which is why many API rate-limit strategies bucket requests by key.
• Access scoping — better providers let you issue keys with restricted permissions (read-only, a single product area) so a leak does less damage.
• Revocation — if a key is exposed, you delete it and issue a new one without disturbing your account password.

When you use one (and when you should not)

API keys fit best when the caller is a trusted server. A backend talking to a payment gateway, a search index, or an email service is the textbook case: the key lives on a machine you control and never reaches an end user.

They fit poorly in any code the public can read. A key embedded in a single-page web app, a mobile binary, or a public repository is effectively published, since browsers and decompilers expose it. If a public client must reach a protected API, route the call through your own backend, or use a short-lived token minted server-side, so the secret never leaves your infrastructure.

Common pitfalls and how to avoid them

Most API-key incidents trace back to a handful of repeatable mistakes.

1. Committing keys to version control. Keys pushed to Git stay in the history even after you delete the line. Keep them in environment variables and add the env file to .gitignore. Before sharing a config publicly, scrub it with an .env redactor.
2. Putting keys in front-end code. Anything shipped to the browser is visible in DevTools. Treat the client as public.
3. Using one key everywhere. Separate keys per environment and service limit the blast radius and make rotation painless.
4. Never rotating. Rotate on a schedule and immediately whenever exposure is suspected. Revoke the old key only after the new one is deployed.
5. Over-scoping. Grant a key the least access it needs. A read-only key cannot delete your data if it leaks.
6. Logging the key. Avoid keys in URLs and scrub them from application logs and error reports.

When you do generate your own secrets — for an internal service, say — make them long and random rather than memorable. A dedicated password generator produces high-entropy strings suitable for use as keys or signing secrets.

Key takeaways

An API key is a shared secret that identifies the caller of an API and underpins billing, quotas, and rate limiting. It is ideal for server-to-server use, but because possession alone grants access, it is weaker than token-based authentication and must never appear in public client code. Store keys in environment variables, scope them narrowly, rotate them regularly, and revoke any key the moment you suspect it has leaked.

Frequently Asked Questions