API Keys
An API key belongs to an organization, not to a person. You can hold several — one per environment or service — and they all authenticate the same way and spend the same credit balance.
How keys are scoped
Every key is owned by an organization. That ownership decides three things: which credit balance the call spends, which rate limit applies, and whose usage history it lands in. Two keys in the same organization are interchangeable in all three respects.
| Property | Scope |
|---|---|
| Header | X-renidly-apikey |
| Credits spent | The organization’s single shared balance |
| Rate limit | The organization's limit — see Rate Limits |
| Endpoint access | Full access to every endpoint your plan exposes |
| Maximum per organization | 7 |
One key per environment
Because keys share one balance, there is no cost to splitting them — and real benefit. Give each environment its own named key:
- You can revoke a leaked CI key without touching production.
- Logs and analytics can be filtered per key, so you can see what staging is actually doing.
- Rotating one environment does not force a coordinated rollout across all of them.
Create and name keys in API Keys. Owners and Admins can manage them; other roles cannot see key values at all.
Storing your key
- Copy the value from API Keys when you create it.
- Store it in a secret manager (1Password, Vault, AWS Secrets Manager, Doppler).
- Reference it as
RENIDLY_API_KEYin your runtime — never commit it.
Rotate vs revoke
Both take effect immediately — there is no grace period on either. The difference is what happens to the key's identity and history.
| Rotate | Revoke | |
|---|---|---|
| The old secret | Stops working at once | Stops working at once |
| You get a new secret | Yes | No — the key is gone |
| Name and usage history | Kept | Deleted with the key |
| Use when | A secret leaked but you still need the key | The key is no longer needed at all |
Rotating without downtime
- Add a second key named for the rollout (for example
production-next) rather than rotating in place. - Deploy a release that prefers the new key if it is set, falling back to the current one.
- Once every instance is on the new key, revoke the old one.
This uses your key allowance instead of a maintenance window, and at no point are any requests rejected. If you would rather rotate in place, stage the new value in your secret manager first and expect a brief failure window at the cutover.
Permissions and scopes
Today every key has full access to the endpoints your plan exposes. Per-endpoint scopes are on the roadmap. Until then, use separate keys per environment so you can revoke narrowly.
Security incident response
If you suspect a key has leaked:
- Rotate or revoke it from API Keys — the old value stops working at once.
- Filter the request logs to that key and look for unexpected calls.
- Check Organization → Activity to see who last changed keys or members.
- Email [email protected] with the approximate compromise window — we can confirm whether any pre-rotation usage occurred and from what IPs.
- Rotate any other secrets stored alongside the Renidly key.