Root keys vs API keys
| Root Keys | API Keys | |
|---|---|---|
| Purpose | Manage Unkey resources | Authenticate your users |
| Who uses it | You (the developer) | Your customers |
| Permissions | Create/update/delete keys, manage APIs | Access your API endpoints |
| Where stored | Your server’s environment variables | Given to customers |
Create a root key
Go to Settings
Navigate to Settings → Root Keys in your dashboard.
Configure permissions
Give the key a descriptive name and select only the permissions it needs.
Common permission sets:

| Use case | Permissions needed |
|---|---|
| Verify keys only | api.*.read_key |
| Create keys for users | api.*.create_key, api.*.read_key |
| Full key management | api.*.create_key, api.*.read_key, api.*.update_key, api.*.delete_key |
| Rate limit overrides | ratelimit.*.set_override |
| Key encryption | encrypt_key |
| Key decryption | decrypt_key |
Permissions system
Root keys use fine-grained permissions to control what operations they can perform. Always follow the principle of least privilege.API permissions
api.*.create_key- Create new API keysapi.*.read_key- Read and verify API keysapi.*.update_key- Update existing API keysapi.*.delete_key- Delete API keys
Rate limiting permissions
ratelimit.*.set_override- Create and modify rate limit overridesratelimit.*.list_override- List rate limit overridesratelimit.*.delete_override- Remove rate limit overrides
Encryption permissions
encrypt_key- Store keys in encrypted vault for recoverydecrypt_key- Decrypt and retrieve keys from vault
Best practices
Use minimal permissions
Use minimal permissions
Only grant the permissions each root key actually needs. A key that only verifies API keys doesn’t need
delete_key permission.Use separate keys for different services
Use separate keys for different services
Create dedicated root keys for each service or environment:
production-api-server— verify and create keysadmin-dashboard— full management accessbilling-service— update key credits only
Rotate keys periodically
Rotate keys periodically
Even without a breach, rotate root keys every few months as a security practice. Create a new key, update your services, then delete the old one.Rotation workflow:
- Create a new root key with the same permissions
- Update environment variables in your services
- Deploy the updated configuration
- Verify the new key is working
- Delete the old root key
- Check audit logs to confirm no usage of old key
Never log root keys
Never log root keys
Ensure your logging doesn’t capture root keys in request bodies or headers. Configure your logging framework to redact Authorization headers.
If a root key is leaked
Act immediately:- Revoke the key — Go to Settings → Root Keys and delete the compromised key
- Create a new key — Generate a replacement with the same permissions
- Update your services — Deploy the new key to your environment
- Check audit logs — Review Audit Logs for any unauthorized activity
- Rotate affected API keys — If you suspect API keys were created or modified, consider rotating them
GitHub secret scanning automatically detects leaked Unkey root keys in public repositories. You’ll receive an email alert if your key is found. Learn more →
Environment-specific keys
Create separate root keys for each environment:- Development mistakes don’t affect production
- You can revoke development keys without impacting production
- Audit logs clearly show which environment made each request
Next steps
Key Recovery
Learn about recovering leaked keys
Audit Logs
Monitor root key usage

