Best Practices for API Key Management and Rotation

How Can I Effectively Manage API Keys?

Effective API key management starts with treating every key as a production credential. A key may look like a random string, but in practice it can unlock data, spend money, create accounts, change records, or give an attacker a trusted path into an API. The right question is not only "where do we store the key?" It is "who owns this key, what can it do, how is it used, and what happens when its behaviour changes?"

Good API key management combines inventory, least privilege, secure storage, rotation, monitoring, rate limits, and fast revocation. It also belongs inside a wider API security model, because a valid key can still be abused.

For a lifecycle view of service tokens, API keys, and other non-human credentials, see the service token and machine credential lifecycle guide. This page focuses on the operating controls that keep keys useful without turning them into permanent, unreviewed access.

Keep an API Key Inventory

Teams lose control when keys are created for one integration, copied into another service, and never reviewed again. Maintain an inventory that records the owner, application, environment, scope, creation date, last use, rotation date, and approved routes for each key.

An inventory makes cleanup possible. It also helps incident response. If a key appears in logs, source control, a support ticket, or a breach report, the team should be able to see what it can access and how quickly it can be disabled.

Scope Keys to the Job

Do not use one broad API key across multiple services, environments, or partners. Create separate keys for development, staging, production, internal services, partners, and high-risk workflows. A read-only reporting key should not be able to write customer data. A partner key should not be able to call private administrative routes.

This is the practical version of least privilege. Smaller scopes reduce the blast radius when a key leaks and make abuse easier to understand when traffic changes.

Store Keys as Secrets

API keys should not be hardcoded, checked into source control, pasted into tickets, or stored in plain text configuration. Use a secrets manager or equivalent controlled storage with access control, audit logs, and encryption. Environment variables can be useful for simple deployments, but production systems still need ownership, review, and auditability around how those variables are set and changed.

Transmission matters too. API calls should use TLS, and systems that receive keys should avoid logging the full value. Where practical, store only a hash or key identifier for lookup and keep the secret itself out of routine logs.

Rotate Without Breaking Production

Rotation limits the useful life of a leaked key, but manual rotation often fails because it is risky and disruptive. Design key rotation so the old and new keys can overlap for a short transition, then revoke the old key once traffic has moved.

The rotation schedule should reflect the key's risk. A low-privilege reporting key may not need the same cadence as a production payment, identity, or administrative integration. The important part is that rotation is tested before an incident forces the team to do it under pressure.

Monitor Key Behaviour

API key monitoring should show how a key is being used, not just whether it authenticated successfully. Useful evidence includes route, method, status code, source network, ASN, country, user agent, request rate, error rate, response size, and time of day.

The signal becomes stronger when it is tied to expected behaviour. A partner key that normally calls one endpoint from one region should not suddenly scan every route from a residential proxy network. A mobile key should not be reused across impossible volumes, new fingerprints, and failed account workflows. That is where API key management connects to bot management, residential proxy detection, and anomaly detection.

The useful review question is not only "did the key authenticate?" It is "does this request still match the key's job?" A valid key used on a new route, from a new client, at a new rate, or after suspicious account activity deserves a different decision from normal partner traffic.

Enforce Rate Limits and Quotas

Keys need traffic controls. Basic quotas protect cost and availability. Route-aware API rate limiting protects sensitive workflows such as login, search, checkout, account change, and data export. The limit should not only count by IP address. Mature controls can include key, route, identity, country, ASN, response code, fingerprint, and recent behaviour.

For abusive or uncertain traffic, advanced rate limiting gives teams more options than a hard block. A key can be slowed, challenged through the associated session, restricted to lower-risk routes, logged for review, or revoked when the evidence is clear.

The rate-limit decision matrix is the practical companion here. Use it to define the route, key, interval, action, and customer impact before enforcement changes go live.

Revoke Fast When Risk Changes

Revocation should be a normal operating action, not a last resort. Revoke keys that are unused, ownerless, over-scoped, found in code, exposed in logs, tied to a departed partner, or involved in suspicious behaviour. Keep the decision record: which key was revoked, why, what access was removed, and what downstream systems were notified.

If a key is compromised, assume the attacker may already have used it. Review what it accessed, which records changed, whether rate limits were hit, and whether new keys or accounts were created from the same activity.

Where Peakhour Fits

Peakhour's API Protection helps teams make request decisions around APIs, not just authentication decisions. API key management tells you whether a caller is allowed to present a credential. API security still needs to ask whether the request is expected, whether it fits the route, whether the rate is reasonable, and whether automation or proxy signals change the risk.

That is the practical aim: keep API keys owned, scoped, stored, rotated, monitored, and revocable, then use request context to stop valid credentials from becoming an open path for unwanted automation.