An API key is a simple secret string that a client includes with its requests to an API in order to identify and authenticate itself. It is one of the oldest and most common ways to control access to a web service: the provider issues a unique key to each developer or application, and the service checks that key on every incoming request. Stripe’s documentation states the pattern plainly: “Stripe authenticates API requests using your account’s API keys. If a request doesn’t include a valid key, Stripe returns an invalid request error.”
API keys are valued for their simplicity. There is no multi-step handshake and no token exchange; the caller just attaches the key, usually in an HTTP header, and the server looks it up to identify the account and apply rate limits, quotas, and permissions. This makes keys ideal for server-to-server calls and for metering usage, which is why nearly every commercial API hands one out as the first step of onboarding.
Many providers distinguish between keys meant for different exposure. Stripe, for example, separates publishable keys, which it describes as a key “that you can put in front-end code or applications you distribute,” from secret keys, which “have unrestricted permissions on all Stripe APIs.” Only the publishable keys are safe to expose; the secret keys must be guarded. Stripe’s guidance is to store sensitive keys in a secrets vault and warns against putting them “in source code or configuration files checked into version control,” advice that captures the central operational hazard of API keys: a leaked key is a leaked credential.
The limitations follow from the same simplicity that makes keys attractive. A bare API key is a long-lived bearer secret. Anyone who obtains it can act as the legitimate caller, the key carries no information about an end user’s consent, and rotating or revoking it requires the provider’s own tooling. Because the key travels with every request, it must be sent over an encrypted transport such as HTTPS to avoid interception.
This is where API keys diverge from OAuth. An API key authenticates an application to a service and answers “which account is calling,” but it was never designed to let one user grant another application limited, revocable access to their data. OAuth 2.0 fills that gap with scoped, expiring access tokens issued only after a user consents, often carried as JWTs. In practice the two coexist: API keys remain the workhorse for identifying applications and billing for usage, while OAuth handles delegated access on behalf of users.