Dashboard
Keys and security
Create one key per tool, limit what it can spend, and rotate it without downtime.
An API key spends your credit, so treat it like a password.
Create one key per tool
Make a key for each tool, script or teammate. Name it after what uses it. When a key leaks or a tool is retired, you disable one key and nothing else breaks. Activity shows the key on every request, so you can see which tool spent what.
Cap the damage
| Setting | Use |
|---|---|
| Credit limit | Sets what the key may spend in total. A key at its limit returns 402 key_limit_reached |
| Expires | Never, 7 days, 30 days or 90 days. Use a short expiry for a demo or a contractor |
The credit limit counts what the key has spent and what its running requests hold. A request whose hold does not fit in what is left is refused with 402 key_limit_reached, except on Chat completions without server tools, which can run it with a lower max_tokens. See Pricing.
Store keys
- Keep keys in environment variables or a secret manager, never in source code.
- A key is shown once, when you create it. Deference stores only a hash and the characters the dashboard shows, such as
sk-df-Ab3x…Qz9k, so a lost key cannot be recovered. - Do not paste keys into chats, tickets or screenshots.
- Add
.envto.gitignore.
Rotate
- Create a new key with the same limit.
- Update the tool or secret to use it.
- Confirm requests appear under the new key in Activity.
- Disable the old key.
If a key leaks
Disable it in API keys right away. Requests with it fail with 401 api_key_disabled. Disabling is reversible. To remove a key permanently, disable it and then delete it. Check Activity for requests you do not recognize.
Keep it server-side
Do not ship a key in a browser app or a mobile app. Anyone can read it. Call Deference from a server and give each user your own access rules.