Skip to main content
Custom API keys let you create additional keys beyond your main account key. Each key can have its own budget, expiration, and type, giving you fine-grained control over access and spending.

Use Cases

  • Environment separation — dedicated keys for development, staging, and production
  • Team access — separate keys for different team members or projects
  • Budget control — set credit limits per key to cap spending
  • Security — rotate or revoke individual keys without affecting other integrations
  • Usage tracking — monitor consumption per key

Token Types

Sandbox keys return simulated responses and do not incur any cost. They are ideal for development and CI pipelines. See the Sandbox guide.

Two Ways to Manage Keys

From the dashboard. Any user can create, edit, rotate and revoke keys on the API Keys page. This is all you need for a handful of keys. Through the Management API. Organizations that provision keys from automation (CI, an internal portal, onboarding scripts) use the /v3/manage/keys endpoints documented below. These endpoints are not called with an inference key: they need a management key (mgmt-eden-…) with the manage:read scope to read and manage:write to create, update, rotate or revoke. Generate one from the dashboard (Account → Management Keys) or mint it with an issuer key, as explained in the Management API guide.
Calling a /v3/manage endpoint with an inference key (sk-eden-…) returns 401 with a message asking for a management key.

API Endpoints

All requests use Authorization: Bearer <management_key> and act on the organization the management key belongs to. Keys are addressed by their id (a UUID returned on create and in the list), not by name. The full request and response schemas are in the Organization Management section of the V3 API Reference.

Create a Key

The response is the key resource plus a secret field:
secret is returned only in this response and cannot be retrieved later. Store it immediately. If you lose it, rotate the key to get a new secret.
Request fields: Creating a key returns 403 if your plan’s key limit is reached.

Create a Key with Budget

Set a spending limit with balance:
When active_balance is true, every API call deducts from the key’s balance. Once it reaches $0, the key stops working. In responses, balance is the remaining amount (a number), or null when the key has no spending cap.

Periodic Budget Reset

A budget can either reinitialize automatically each day, week, or month, or be a one-time allowance that stays at $0 once spent until you top it up manually. You control this with balance_reset_period (the reset frequency) and balance_reset_amount (the amount the balance is restored to at the start of each period).

In the dashboard

On the API Keys page, create or edit a key and turn on Spending Limit. Set the Reset allowance (the amount restored each period) and choose a Resets frequency — Daily, Weekly, Monthly, or Never. A reset frequency is always selected when a spending limit is on; it defaults to Monthly. Choose Never for a one-time budget that does not renew. A separate Current balance field shows what’s available right now; editing the allowance only takes effect at the next reset.

Through the API

Behaviour to know:
  • Setting a reset period automatically enforces the budget (active_balance becomes true) — you don’t have to set it separately.
  • balance_reset_amount is the reset target, kept separate from the live balance (the amount remaining right now). They are not the same field.
  • A new periodic key starts the period full: if you don’t pass a starting balance, it begins at balance_reset_amount. Passing an explicit balance lets a key start partway through a period.
  • Resets run at midnight Europe/Paris time: daily every night, weekly on Monday, monthly on the 1st.
  • Setting the period back to none (with a PATCH) clears balance_reset_amount and returns the key to a one-time budget.
This per-key reset is distinct from the per-member budget cap you can set on a guardrail. A key budget is a hard cap on one key (it stops at $0); a member budget is a soft periodic spend cap that follows a person across all their keys.

List All Keys

The list is paginated (limit, max 100, and offset) and includes revoked keys, flagged with revoked: true. Secrets are never returned; use masked to recognise a key.
A legacy key that was created before keys had ids and has never been regenerated is listed with "id": null. It cannot be addressed by URL until you regenerate it from the dashboard.

Update, Rotate or Revoke a Key

Follow-up operations take the key’s id. Only the fields you send in a PATCH are changed; token_type cannot be changed.
Update the budget
Rotate the secret
Rotating returns {"secret": "sk-eden-...", "masked": "...", "name": "production-v1"}. The previous secret stops working immediately and the new one is shown once.
Revoke
Revoking is permanent: the key stops authenticating immediately, cannot be re-enabled, and stays in the list with revoked: true for your records. The response is 200 with the revoked key.

Best Practices

Use clear naming conventions like env-project-purpose (e.g., prod-billing-api, dev-ml-team) so keys are easy to identify at a glance.
  • Set budgets on non-production keys to prevent accidental overspending during development.
  • Use a periodic reset (balance_reset_period) for recurring allowances — e.g. a $10/day CI key — instead of topping up manually.
  • Use sandbox keys for CI/CD to validate integrations without incurring costs.
  • Rotate keys periodically with the rotate endpoint: the key keeps its id, name and budget, so nothing else needs to change.
  • Set expiration dates on temporary keys (e.g., for contractors or short-term projects).
  • Attribute keys to members with member so usage reports show who spent what.