API Keys

The API Keys page is where operators issue credentials for applications, teams, and controlled integrations.

Access: platform admins and roles with key.read/key.update see authorized keys; eligible team members with key.create_self can manage only their own keys under team policy. See Access requirements, Tenancy and access, and the API-key admin API.

What this page is for

• Create a new key for a team-owned application or integration
• Apply budgets and rate limits across multiple time windows (per-minute, per-hour, per-day)
• Regenerate or revoke keys without changing the integration pattern
• Review ownership and key-level scope context
• Allow team developers to create and manage their own keys via self-service

Quick steps

1. Select the team that should own the key.
2. Choose who owns it in the admin UI: You for a human-owned key, or Service account for automation.
3. If you need a new service account, create it directly from the same dialog after selecting a team.
4. Set optional limits such as budget, RPM, TPM, Output TPM, RPH, RPD, or TPD.
5. Choose whether the key inherits the team asset set or narrows it to selected targets or access groups.
6. Create the key and copy the raw secret immediately. It is only shown once.

Self-Service Key Creation

Team developers with the key.create_self permission can create their own API keys without involving an admin. The page shows two tabs when self-service is available:

• All Keys — visible to admins, showing every key in scope
• My Keys — shows only keys owned by the current user

How it works

1. An admin leaves self-service enabled on the team or enables it later in team settings (see Teams)
2. A team developer signs in and navigates to API Keys
3. The simplified creation form shows policy constraints (max budget, required expiry, etc.)
4. The developer creates a key — the backend forces the owner to the current session user
5. The developer can regenerate, revoke, or delete their own keys

Policy constraints enforced by the backend

Constraint	Effect
Self-service disabled on team	Creation blocked with 403
Max keys per user reached	Creation blocked with 403
Budget exceeds team ceiling	Creation blocked
Missing expiry when team requires it	Creation blocked
Expiry exceeds team max expiry days	Creation blocked
Rate limits exceed team limits	Creation blocked

Self-service users cannot see or manage keys owned by other users through the My Keys view.

Key dialog

The create and edit dialog has three tabs:

• Details: key name, team, and the owner controls available for the operation.
• Access: inherit team access or select a smaller set of targets and access groups.
• Limits: budget, expiry where supported, and rate limits. Open Hourly and daily limits for RPH, RPD, and TPD.

An empty limit adds no key limit. Team and organization limits still apply. The save controls remain visible when the form scrolls. After creation, select Copy key in the one-time key dialog. A failed clipboard operation shows an error so you can copy the displayed key manually.

Key fields

• Key name: human-readable label shown in the table
• Team: required ownership boundary for spend, permissions, and reporting
• Owned by: who the key belongs to in the admin UI
• Max budget: hard spend ceiling for that key
• RPM / TPM: request and token throttles per minute
• Output TPM: actual provider output across text models per completion accounting minute. Leave it blank for no key limit. Admitted calls can exceed the limit; new calls then wait until reset. See Output TPM.
• Model Output TPM: output allowance for each exact callable model. Add or remove rows in the key form. Clearing a key limit keeps its team, organization, and tier limits.
• RPH: request throttle per hour
• RPD / TPD: request and token throttles per day

Last used

The Last used column shows when a key last authenticated a request.

• Never means that DeltaLLM has no recorded use of the key. Keys that were not used after the upgrade that added this column also show Never.
• Recent values show as relative time, for example 5 min ago. Values older than 30 days show the date. Hold the pointer on a value to see the full local time.
• The gateway writes this value in batches about once per minute. The value can be up to one minute old. A replica that stops without a clean shutdown can lose its last minute of values.
• A request with the master key, a JWT, or custom authentication does not change the value.
• A regenerated key keeps its last used time. A deleted key removes it.

Use this column to find keys that are not in use before you revoke them.

Key Asset Access

Keys normally inherit the callable-target universe from their team. Use key-level restriction when an integration needs a smaller model set than the team owns.

In restrict mode, a key can select direct callable targets and access groups already visible through the team. An access-group grant gives the key access to the group's current callable targets. After runtime reload, it also includes new matching targets. The team and organization must permit each target.

Self-service keys follow the team's self-service policy and ownership rules. They still inherit the team asset boundary; admins can use the full key editor when a production integration needs explicit key-level narrowing.

The default team policy controls personal key creation for self-registered sandbox users. The key must remain within the sandbox team. The current user becomes its owner. The requested budget, expiry, and rate limits must obey the team's self-service policy. Runtime requests still use the normal budget and rate-limit checks for the organization, team, runtime user, and key.

Important behavior

• The raw key is shown once at creation time
• The table keeps the hashed token, owner, status, and budget progress
• Scoped access still applies: org users only see keys inside their organizations
• Service accounts are non-login owners for shared services, jobs, or automations
• Keys no longer carry model allowlists on the key record. The create/edit dialog writes callable-target bindings, access-group bindings, and scope policies so a key can inherit its team asset set or narrow it further.
• When rate limits are updated via the admin API or UI, the key validation cache is automatically invalidated so new limits take effect immediately

Keys with a Console customer session

An external customer session can list, create, revoke, and delete its own keys in its fixed team, subject to the team's self-service policy. It cannot regenerate keys, change ownership or budgets, or administer another customer's keys. Playground selection requires the exact mapped account, runtime user, and team.

Revocation can return pending while durable cache invalidation completes. The UI shows this state and polls enforcement status. With the enabled feature's maximum 60-second cache lifetime, enforcement is bounded by 61 seconds. Signing out closes browser sessions; application keys remain active until explicitly revoked or blocked by inference controls.