DurinDoorAPI key scoping
Limit a client key to selected accounts without accidentally widening access.
Limit each client key to the provider accounts that client may use. A key with no selected accounts can use every otherwise eligible provider account. Model restrictions apply in addition to account restrictions.
Restrict a key
- Open Dashboard → API Keys (
/dashboard/keys). - Create or edit the client's key.
- In Provider accounts, select at least one existing connection.
- Save the key and send a request with it.
- Confirm in Usage that the request used an allowed account.
Use a separate key for each client. Add model restrictions and expiry where needed.
Change the restriction through the API
The management key endpoints accept providerConnectionIds on create and update:
| Request | Effect |
|---|---|
POST /api/keys with a nonempty list | Create a key limited to those connection IDs. |
PUT /api/keys/<id> with a nonempty list | Replace the selected accounts. |
PUT /api/keys/<id> without the field | Keep the existing selection. |
PUT /api/keys/<id> with [] | Remove the restriction and allow all eligible accounts. |
Use your authenticated management API connection. GET /api/keys returns available account IDs, names, and providers without their credentials. Invalid, missing, or duplicate IDs return HTTP 400 and do not change the key.
Remove an account without widening access
Deleting the final selected account for any key returns HTTP 409 with API_KEY_SCOPE_WOULD_BROADEN. This also applies to bulk and provider-node deletion.
Before retrying, revoke the affected key or select another account for it. Clear its account selection only when you intend unrestricted account access. An empty selection restores broad access rather than denying all access.
Check native resource boundaries
Native HTTP and WebSocket requests apply account and model restrictions, including nested execution models. Account-bound operations require x-connection-id; a failed pin cannot select a sibling account.
A tracked native resource belongs to its creating API key. Completion usage is charged to that creator. Polling, cancellation, and deletion enforce ownership before contacting the vendor. Deleting the creator's key does not transfer charges to a polling key.
Anthropic file and batch operations and MiniMax voice-category lists retain the vendor's account-wide semantics. Give those accounts only to clients you trust with their resources.
Keys with usage or rate limits cannot submit native background or batch inference, or mint direct ephemeral sessions. Gateway-relayed WebSockets can account for reported terminal token usage. A successful request that spends the last allowance returns its output, then the next admission fails.
Token and USD limits do not measure every media charge. Charges per character, image, second, or generation need vendor-side budgets. Account scope limits access; it does not impose a provider spending cap.