Management Keys

A second key class that governs your API keys: create them, cap their spend, expire them, revoke them.

Management keys are a second key class, separate from the API keys that make model calls. A management key governs your account's API keys over the API: create keys, set per-key spend limits, set expirations, inspect usage, and revoke. This is the tool for teams, CI pipelines, and agents that provision their own keys without touching the dashboard.

A management key never makes model calls. It only answers the /v1/management/ endpoints, so a leaked inference key cannot govern your account and a leaked management key cannot spend your credits on inference.

#Creating a management key

Open your dashboard, Management keys, name it, and create. The key is shown once and stored only as a hash; copy it immediately. Keys look like dcode_mgmt_... and can be revoked from the same page at any time.

#Endpoints

Base URL https://api.dipoleml.com. Every call authenticates with Authorization: Bearer <management key>.

Method	Path	What it does
GET	/v1/management/keys	List every API key on the account.
POST	/v1/management/keys	Create an API key.
GET	/v1/management/keys/:id	Fetch one API key.
PATCH	/v1/management/keys/:id	Update label, limit, and/or expiration.
DELETE	/v1/management/keys/:id	Revoke an API key. Immediate.

#Creating API keys

create a limited, expiring key

curl https://api.dipoleml.com/v1/management/keys \
  -H "Authorization: Bearer $DIPOLEML_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "staging bot",
    "limit": 10,
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response returns the new key object with the plaintext in the key field, exactly once, plus 201 Created. limit is a lifetime spend cap in USD for that key. expires_at is an ISO 8601 timestamp. Both are optional; omit them and the key is unlimited and never expires.

#The key object

Field	Meaning
id	Stable identifier, starts with ak_. Used in the path for updates and revocation.
label	Free-text name, up to 80 characters.
status	One of active, expired, or revoked.
limit	Spend cap in USD, or null for no limit.
used	Lifetime spend billed to this key, in USD.
limit_remaining	Limit minus used, or null when unlimited.
expires_at	Expiration as ISO 8601, or null for never.
last_used_at	When the key last completed a billed request.

#Limits and expiration

Enforcement runs in order on every request: first the key's expiration, then its per-key limit, then the account's credit balance. Over the limit, the call is rejected with HTTP 402 and code key_limit_reached; past expiration, with HTTP 401 and code key_expired. An empty account balance returns the standard insufficient_credits 402 once the key itself is valid.

raise a limit, then remove it

curl -X PATCH https://api.dipoleml.com/v1/management/keys/ak_1a2b3c4d \
  -H "Authorization: Bearer $DIPOLEML_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit": 25}'

remove the limit entirely and set a new expiration

curl -X PATCH https://api.dipoleml.com/v1/management/keys/ak_1a2b3c4d \
  -H "Authorization: Bearer $DIPOLEML_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit": null, "expires_at": "2027-03-31T00:00:00Z"}'

The same controls exist without code: every API key on the dashboard API keys page carries a spend limit and expiration, editable in place.

#Revoking

DELETE /v1/management/keys/:id sets the key's revoked timestamp; the very next request with it fails authentication. Listing still includes revoked keys with status: "revoked" so your records stay auditable.

#Security notes

Management keys are shown once and stored hashed; treat them like root access to your key provisioning.
Revoke immediately if one leaks, rotate your CI secrets on the same schedule as your inference keys.
Use narrow limits on keys you hand to machines: a staging key with a $10 cap cannot surprise you.