API Key Management: A Practical Guide

Manage API keys as credentials: generate a distinct key for each application or service, keep secret keys on the server, grant only the access each task needs, and monitor use. Set rotation and transition plans for the credential and its risk—not a universal calendar interval.

Key takeaways

• Keep secret keys out of browser or mobile client code and source repositories.
• Use separate credentials where needed, narrow their permissions, and remove keys that are no longer used.
• Choose monitoring, rotation and revocation steps that fit the key's provider, purpose and risk.

Create, store and control keys

1. Generate: Use a trusted provider or cryptographically secure generator; create distinct credentials for different applications or services.
2. Store: Keep secret keys in a server-side secret store or protected server configuration, not in client code or a repository. Restrict who and what can read them.
3. Limit: Apply the narrowest permissions and provider-supported restrictions that fit the use case. Remove unused keys.
4. Monitor: Review access and usage logs for activity outside the expected pattern.
5. Rotate and revoke: Plan a tested transition appropriate to the credential and risk, then revoke the old key. Revoke promptly if it is suspected to be exposed.
6. Compare tools: AWS Secrets Manager, HashiCorp Vault and other options may be evaluated against your requirements.

Selected secret-management pricing

Official pricing checked October 7, 2026. These are different products and billing units; compare them against your own usage and requirements.

See the vendors' AWS Secrets Manager pricing and Infisical pricing pages for current terms.

Keep secret keys out of client code

Create and store keys safely

Choose a credential format and lifecycle supported by the API provider. Keep each secret identifiable to its owner, application and purpose so it can be restricted, monitored and replaced.

Creating Strong Keys

When generating keys, follow these guidelines:

• Generate keys with a provider-supported mechanism or a cryptographically secure random generator; do not invent credentials by hand.
• Use distinct keys for separate applications or services where practical, so access and activity can be managed separately.

You can automate this process with secure libraries like crypto in Node.js or secrets in Python. These tools simplify the creation of secure, random strings.

Use an unmistakable placeholder in documentation and examples, never a credential that resembles a working key:

API_KEY=<PLACEHOLDER_NOT_A_REAL_KEY>

Once you’ve generated strong keys, the next step is to store them securely.

Storing Keys Safely

1. Environment Variables

Never embed secret API keys in client-side code or commit them to a repository. Google Cloud specifically advises routing client requests through a server, which can add the credential before calling the API; that guidance concerns Google API keys and should not be treated as a provider-neutral implementation requirement. Google Cloud API-key guidance.

# Illustrative placeholder only; do not commit real credentials
API_KEY="PLACEHOLDER_NOT_A_REAL_KEY"

2. Encryption at Rest

Use a secret store or other protected server-side configuration with access controls. Follow the provider's supported protection and backup procedures; do not assume a single encryption or rotation setting fits every system.

3. Access Controls

Limit access to key storage systems using role-based access control (RBAC). Additionally, set up audit logging to monitor any access attempts.

Setting Key Permissions

Use the API provider's documented scopes and permission model; available scopes, rate limits, IP restrictions, and expiration options vary by provider and API.

For sensitive operations, check whether the provider offers a more suitable authorization method than a long-lived API key, and choose according to the service's authentication model.

Managing Key Lifecycles

Track where each key is used and who owns it, so you can investigate unusual activity and update or revoke the right credential.

Tracking Key Usage

Keeping an eye on how keys are being used helps identify unusual activity and potential security threats. To do this, set up logging systems that capture:

• Frequency and timing of requests
• IP addresses and geographic locations
• Patterns of endpoint access
• Response codes and error rates
• Data transfer volumes

Use dashboards to make these metrics easier to interpret:

Set alerts around expected use for your service rather than applying generic numerical thresholds. Google Cloud recommends monitoring and logging API usage; see its provider-specific guidance.

Key Rotation Steps

1. Set the policy: Choose a rotation cadence based on the credential's purpose, exposure and impact. OWASP notes that secret lifetimes vary with their function and what they protect; it excludes user credentials from routine rotation and recommends changing them if compromise is suspected or evidenced. OWASP Secrets Management Cheat Sheet.
2. Create and test the replacement: Follow the provider's rotation procedure and confirm the new credential works in each dependent service.
3. Transition deliberately: If the credential and provider support overlap, allow only the transition needed to test and update consumers, accounting for the exposure risk. There is no universal overlap period.
4. Revoke the old key: Confirm dependent systems have moved, revoke the previous credential, and review logs. If exposure is suspected, prioritize containment rather than waiting for a routine transition.

If rotation isn't enough or a security breach occurs, follow these removal steps.

Key Removal Process

In the event of a security incident, act promptly by following these steps:

1. Immediate Deactivation
   Disable compromised keys through your management console or API.
2. System Notification
   Inform all connected systems about the key deactivation immediately.
3. Access Logs Review
   Examine recent logs for signs of unauthorized access.
4. Incident Documentation
   Record all relevant details, including:
   • Time and date of detection
   • Affected systems and services
   • Actions taken
   • Impact assessment

After revocation, update dependent systems and review access logs. Where the provider supports it, test whether the relevant service rejects the revoked credential; that check does not establish overall or continuing security.

Key Management Tools

This section highlights tools for managing API keys effectively, focusing on secret storage, security gateways, and usage analysis.

Secret Storage Tools

The prices below are from official vendor pages checked October 7, 2026. AWS charges by secret and API calls; Infisical Secrets Management Pro is priced per identity. Confirm current terms and estimate costs for your own use before choosing.

Pricing and plan details can change; consult each vendor's pricing page before purchase.

Other tools to evaluate

These named services are examples to investigate, not a feature or performance ranking. Check each provider's current documentation and terms for fit:

• Kong Gateway
• Apigee

For usage analysis, also evaluate Elastic Stack and Splunk against your monitoring needs.

Deploy with least privilege

Limit a key to the permissions and services it needs. Where the provider supports it, restrict accepted APIs, applications or source networks, and review those settings when use changes. Google Cloud recommends key restrictions and deleting keys that are no longer needed; these are Google-specific controls and should be adapted to the provider in use (Google Cloud best practices).

Code Security Rules

Keep credentials out of code and limit access throughout development and deployment:

For additional provider documentation, see Azure Key Vault and AWS Systems Manager Parameter Store; check each service's documentation to confirm it meets your deployment requirements.

Protect keys in transit

Never transmit secrets in plaintext. Use TLS for connections and avoid putting credentials in URLs or logs. OWASP recommends TLS for transmitting secrets; see its Secrets Management Cheat Sheet.

Permission Controls

Tight access controls reduce the risk of unauthorized key usage and potential breaches:

Use additional authentication controls only when they fit the provider, architecture and threat model. Do not assume that a particular token lifetime or control is suitable for every service.

Related posts

• API Vulnerability Risks in Identity Verification
• AI and US Children's Privacy Laws: Key Rules
• AI and Privacy: Key Principles for Compliance
• ISO/IEC AI Compliance: Key Documentation Standards