The client sends it in a defined request location, commonly an HTTP header. Depending on the design, the key may act as a shared secret, a public identifier, or both.
API keys are commonly long-lived and do not usually identify the individual user behind a request. Secure operation requires an owner, a defined purpose, the narrowest practical permissions and environment, protected delivery and storage, usage monitoring, rotation, and prompt revocation. Keys should not be embedded in public client code or placed in URLs where logs and intermediaries may record them.
Key points
Primary roleLet an API recognize and apply policy to a calling client, workload, project, or subscription.
Authorization boundaryEnforce permissions at every endpoint; possession of a key should not bypass object-level or function-level authorization.
Operational controlsIssue separate keys per consumer and environment, restrict where they can be used, monitor abnormal volume, and maintain a tested replacement process.
Important limitationAn API key is often a replayable bearer secret and may provide weak attribution when shared. It is not automatically user authentication, delegated authorization, encryption, or proof that a request is legitimate.