API Key
Secret credential used to authenticate API requests.
An API key is a credential that identifies an application or project when it sends requests to an application programming interface. A provider may use the key to authenticate requests, apply permissions, measure usage, and enforce quotas. Secret API keys must be protected, while explicitly publishable client keys still need restrictions because anyone can copy them.
An API key is usually a generated string included in an authorization header or another documented request field. It is simpler than an interactive user login and works well for server-to-server access. Unlike OAuth, a basic key may identify the calling application without identifying the individual user or supporting delegated consent. The security properties depend on how the provider implements scopes, expiration, signatures, and request restrictions.
API keys matter because a leaked credential can expose private data, create large usage bills, send messages, modify infrastructure, or authorize other sensitive operations. A key committed to a public repository can be collected by automated scanners within minutes. Hiding it in frontend JavaScript, a mobile binary, or an obfuscated file does not protect it because users control those clients.
Store server credentials in a managed secrets service or an appropriately protected runtime environment, not directly in source code. Create separate keys for each application, environment, and purpose so one incident has a limited effect. Grant only necessary scopes and use expiration dates, IP allowlists, referrer restrictions, usage caps, or service identities when supported. Access to production secrets should be logged and limited to the people and workloads that need it.
For example, a blockchain data API key used by a public website may need read-only access and a restrictive quota. A backend deployment key might require broader rights but should never reach the browser. If a CI system needs the key, inject it from the platform's secret store and prevent command output from printing it. Logs and error trackers must redact credentials.
Rotation should be a tested routine, not only an emergency response. Systems can accept a new key, deploy it, confirm traffic, and then revoke the old one. If exposure occurs, revoke first, investigate logs and billing, replace the credential, and correct the source. Removing the visible key from Git history does not make it safe. API keys are passwords for software, and their management deserves the same care as any production credential.
Frequently asked questions
- Keep secret API keys out of browser code, mobile app bundles, chat, tickets, and source control. Load them on trusted servers from a secrets manager or protected environment, and restrict access by service identity. Use separate keys for development and production, grant minimum permissions, set network restrictions where supported, and rotate credentials without causing downtime.
- Revoke or disable the exposed key immediately, then create a replacement through a secure process. Review provider and application logs for unauthorized requests, unexpected costs, data access, or configuration changes. Remove the key from published code and build history, but do not assume deleting a commit makes it secret again. Document the incident and fix the exposure path.
- Providers limit requests to protect capacity, control costs, and enforce plan quotas. Inspect the response status, headers, and documentation to learn the relevant limit and reset time. Reduce unnecessary calls with caching, batching, pagination, and request deduplication. Apply exponential backoff with jitter instead of retrying continuously, and request a higher quota only after measuring legitimate demand.