Glossary · 2 · Developer SDKs and APIs
API key
Also known as: developer key, app key, API key string
German: API-Schlüssel
In software engineering, an API key is a static secret string that a client sends with every API request so the service can recognize the calling application, project, or subscription. Unlike a login, it normally says nothing about which human is behind the request: Google Cloud documents that a standard API key does not identify a principal and provides no authorization information, and that it mainly associates the request with a project for billing and quota purposes. Because the key is a bearer credential that never expires by itself, anyone who obtains the string can use it until it is revoked. API keys are not defined by a single standard; the OpenAPI Specification describes how to document them as the "apiKey" security scheme in a header, query parameter, or cookie.
- API
- authentication
- credentials
- security
- developer SDK
In one sentence
Static secret identifying a calling app or project to an API: how it differs from user authentication and access tokens, plus storage and rotation.
Example
The SDK reads the API key from an environment variable at startup and sends it in an X-API-Key header, so the provider can attribute the requests to the customer's project and enforce its rate limit.
How it applies
- Developer SDKs: most client libraries for APIs and cloud services take the key at construction time and attach it to each call, so application code never builds the header itself. Document which constructor argument, configuration file, or environment variable the SDK reads, and what happens when the key is missing, malformed, or revoked.
- Documenting the transport: the OpenAPI Specification 3.1.0 models an API key as a security scheme with
type: apiKeyplus the required fieldsname(the header, query, or cookie parameter) andin(query,header, orcookie). Keeping the machine-readable description in the interface definition means generated clients and reference docs agree on where the key goes. - Transport hygiene: keys in query strings tend to survive in server logs, proxy logs, and referrer headers; a request header over TLS is the usual choice. State the required transport explicitly in the REST API reference rather than leaving it to the reader.
- Scoping and restrictions: where the platform supports it, restrict a key to specific APIs, IP ranges, referrers, or apps, and issue separate keys per application and per environment. Restrictions reduce blast radius; they are not a substitute for authorization checks on the server.
- Storage: treat the key as a secret, not as configuration trivia. Read it from a secret manager, environment variable, or platform keystore; keep it out of version control, client-side bundles, and screenshots. In samples and tutorials use obvious placeholders such as
YOUR_API_KEY. - Rotation and revocation: document how to create a second key, deploy it, and delete the old one, and whether the service accepts two valid keys during the overlap. Without an overlap window, rotation means downtime, which is why rotation gets skipped in practice.
- Publishing SDKs: build scripts and multichannel pipelines often authenticate to a content delivery or review service with a key held by the build agent. Because these keys sit in CI configuration, they belong in the pipeline's secret store and in the rotation plan for build infrastructure.
- Platform SDKs: a host application may issue a key per add-in or extension so its backend can recognize the extension. Anything shipped inside a distributable extension package is readable by users, so such keys should carry no privileges beyond identification.
- Hardware SDKs: device and gateway SDKs use per-device or per-fleet keys for telemetry ingestion. Keys provisioned into firmware or flash can be extracted from a device in the field, and constrained devices may be hard to re-provision — both points belong in the security section of the device documentation.
- Telemetry: exclude key values from logging, distributed tracing, and crash reports, and redact them in support bundles. Key identifiers or hashed prefixes are safer correlation handles than the secret itself.
- Compliance caution: using API keys, an SDK, or any specification named here does not by itself make a system secure or compliant; the controls that apply come from the applicable law, contract, or security requirements.
API key vs. access token
An API key is a long-lived static string, usually generated in a provider console, with no standard format, no built-in expiry, and no scopes beyond whatever restrictions the platform adds. An OAuth 2.0 access token is different in kind: RFC 6749 describes access tokens as credentials used to access protected resources — a string representing an authorization issued to the client, carrying specific scopes and durations of access. Tokens are short-lived and obtained through a grant flow, so a leaked token expires; a leaked key stays valid until someone revokes it.
Both differ again from user authentication. A key identifies the calling project or application, not the person using it, so audit trails built on keys cannot attribute actions to individual end users. When per-user identity, consent, or delegated access matters, an API key is the wrong instrument.