directrateGetting started
Authentication
One header, x-api-key. Keys belong to an account; the account carries the plan and the quota.
The header
x-api-key: dr_live_…on every /v1/* request. There is no OAuth, no bearer token, no signing. Keys are created in the
dashboard — the plaintext is shown once at creation and never again, because only a
hash is stored. An account may hold up to five active keys; name them by the thing that uses them.
Accounts, plans, quotas
The plan and the monthly credit allowance belong to the account, not the key. Five keys on a Free
account share one allowance of 250 credits, not five. GET /v1/usage says so:
The account’s credit position this period. A quota belongs to the ACCOUNT: every key of the same account draws on one allowance, so
credits_usedis the account’s spend andcredits_used_this_keyis this key’s share of it. Free to call, and still answered when the quota is exhausted.
{ "plan": "free", "period": "2026-10", "credits_used": 182, "credits_used_this_key": 40,
"credits_limit": 250, "credits_remaining": 68, "rate_limit_rps": 2 }When it fails
| Status | error.code |
Meaning | Billed |
|---|---|---|---|
| 401 | auth_failed |
missing, malformed, revoked or unknown key | no |
| 429 | quota_exceeded |
the account’s credits for the period are spent | no |
| 429 | rate_limited |
more requests per second than the plan allows; Retry-After is set |
no |
Revoking a key takes effect within about ten seconds everywhere. See Errors for the envelope.
Keep it server-side
A key in a browser or a mobile app is a key anyone can read. Call the API from your backend and pass the result on. The playground keeps a pasted key in session storage only, and the home page’s rate card is a build-time snapshot — it holds no key at all.
Metadata is free
GET /v1/chains (what each source supports and weighs), GET /v1/usage, GET /openapi.json and
GET /status.json cost nothing; the last two need no key.