What is API Key?
Also called API token, secret key.
An API key is a secret string that a client sends with each request to identify itself to a service. It is the simplest form of API credential, easy to issue and to use, but it carries no user identity, usually does not expire on its own, and grants whatever it is permitted to do to anyone who holds it.
Keys are normally passed in an HTTP header on every request. The service looks the key up, resolves it to an account and a permission set, and applies the rate limits and billing attached to it. Because holding the key is itself sufficient proof, the entire security model reduces to keeping the string secret and limiting what that string is allowed to do.
Sound handling is well established. Keep keys on servers rather than in browser code or mobile binaries, store them in a secret manager instead of source control, issue separate keys per environment and per integration so one can be revoked alone, scope each to the minimum permissions it needs, and rotate on a schedule and immediately after any suspected exposure.
Leaked keys are among the most common causes of breaches and unexpected charges, and public code repositories are scanned continuously for them. A subtler error is treating a key as though it identified a person. It identifies a project or an account, so an audit log of key based calls tells you which integration acted, not who asked for it.
Compared with OAuth, keys suit machine to machine access where there is no user to consent and the caller controls both ends. They suit user delegated access poorly, because a key cannot express that a particular person allowed a particular scope. Many services now offer both, and the choice mostly turns on whether a specific human is being represented.
Key points
- A shared secret sent with each request to identify the caller.
- Identifies an account or project, not an individual person.
- Anyone holding the key has whatever access it grants.
- Scope narrowly, separate per environment, and rotate regularly.
- Suits machine to machine access and fits user delegation poorly.
In practice
A backend service calls a translation provider. On the provider's dashboard the team creates a key restricted to the translation endpoint, stores it in their secret manager, and injects it as an environment variable at deploy time. The service sends it in an authorization header on every call. When a developer leaves, the team issues a new key, updates the secret, and revokes the old one without touching any other integration.