The narrative that API keys are broken
Every few months a security post makes the rounds claiming that API keys are fundamentally broken. The argument usually goes: API keys can’t expire automatically, they don’t carry identity claims, they travel in plaintext headers, and any developer with access to a config file can leak one.
All of those things are true. None of them make API keys a bad choice for the majority of integration scenarios.
What API keys actually do well
API keys solve a specific problem cleanly: proving that a caller was provisioned to use this API. They are opaque tokens that are fast to verify (a simple hash comparison), easy to revoke (delete the record), simple to audit (every request carries the key), and universally supported by every HTTP client ever written.
For machine-to-machine integrations — service A calling service B, a backend calling a third-party API, a workflow agent hitting an enrichment API — this is usually all the proof you need. The question “is this caller authenticated?” has a clear answer that doesn’t require a token exchange, a JWKS endpoint, or a session.
The real failure mode is management, not mechanism
When API keys leak, it’s almost never because the mechanism itself failed. It’s because:
- Keys were stored in source code or committed to version control.
- A single key was shared across many services (broad blast radius).
- Keys were never rotated after a team member left.
- There was no audit trail, so a leak was discovered weeks later.
These are operational failures. A JWT with a 24-hour expiry doesn’t protect you from a key committed to a public repository, a compromised CI pipeline, or a developer copy-pasting credentials into a Slack message.
How RequestRocket changes the calculus
RequestRocket’s proxy credential type (credentialAuthType: "key") separates the credential your applications use to call the gateway from the upstream vendor key. Your code never touches the vendor secret.
POST /clients/{clientId}/credentials
{
"credentialType": "proxy",
"credentialAuthType": "key",
"credentialName": "data-pipeline-service",
"credentialRegion": "us-east-1",
"credentialSecret": {
"key": "rr_live_xxxxxxxxxxxxxx"
}
}If rr_live_xxxxxxxxxxxxxx leaks, you rotate just that proxy key — the upstream vendor credential is untouched. Your service gets a new key; the vendor doesn’t even know anything happened.
The target credential holds the actual upstream secret, encrypted at rest with AES-256:
POST /clients/{clientId}/credentials
{
"credentialType": "target",
"credentialAuthType": "key",
"credentialName": "sendgrid-transactional",
"credentialRegion": "us-east-1",
"credentialSecret": {
"key": "SG.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}Constraining what a key can do
A leaked key that can only call one endpoint is a dramatically smaller problem than a key that can call anything. Use rules to limit the scope of each proxy credential:
POST /clients/{clientId}/credentials/{credentialId}/rules
{
"effect": "allow",
"methods": ["POST"],
"path": {
"path": { "pattern": "^/v3/mail/send$" },
"presence": "must_exist"
},
"priority": 10,
"notes": "Transactional email sender: POST /v3/mail/send only"
}With proxyDefaultRuleEffect: "deny" on the proxy, this credential is good for exactly one operation. There is no configuration surface for an attacker to discover and abuse.
When API keys genuinely are the wrong tool
This isn’t a blanket defence. API keys are a poor fit when:
- You need claims-based identity (user ID, roles, tenant ID) to flow through the request. Use JWTs.
- Short-lived tokens are an explicit compliance or security requirement. Use OAuth2.
- The caller is a human authenticating interactively. Use a proper identity flow.
For all other machine-to-machine scenarios, a well-managed API key with appropriate rules and a gateway in front of it is secure, auditable, and operationally simple.
Next steps
If your concern about API keys is really about key sprawl, rotation gaps, or no audit trail — those are solved by the gateway layer, not by switching auth mechanisms. Read the RequestRocket credential documentation to see how proxy and target credentials work together, or start for free.