Get started
Authentication
API keys for the data plane, session cookies for the control plane, and the limits a key can carry.
API keys
Every inference request carries a key in the Authorization header:
Authorization: Bearer sk_i2_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxKeys belong to a project inside your organisation. Usage and spend are attributed to the key, so one key per service or environment is the natural unit: it gives you a clean line in the request log and lets you revoke one integration without touching the others.
The secret is returned exactly once, when the key is created. It is stored hashed; nothing on the platform can show it again. If it is lost, revoke it and mint a new one.
What a key can be limited to
Set on creation (dashboard, or POST /api/keys); enforced by the gateway on every request.
| Limit | Behaviour |
|---|---|
Expiry (expires_at) | After this instant the key answers 401 with "API Key Expired". Must be in the future when set. |
Credit cap (credit_limit_cents, micro-PKR) | A lifetime rupee ceiling for this key alone. At the cap the key answers 402; the rest of the organisation's balance is untouched. |
Allowed models (allowed_models) | A list of route ids. Any other model answers 403 model_scope_error. |
| Environment | A label (production, development, testing) for your own filtering. Nothing enforces it. |
| Rate limit | 60 requests per minute per key, the platform default. Not configurable through the API today; ask us if you need more. |
The key roster in the dashboard, and GET /api/keys, report an enforcement_status per limit, which states whether the gateway currently enforces it. Today all three limits read enforced; the field exists so a client never has to assume that from the field names alone.
Warning
credit_limit_centsis in micro-PKR (1 PKR = 1,000,000), despite the name. Every_centsfield on the platform uses that unit. A cap of Rs 5,000 is5000000000.
Revoking a key
Revoke from the dashboard or with DELETE /api/keys/{key_id}. Revocation reaches the gateway on the very next request: the key's hash is dropped from the hot-path store the moment the control plane saves the change, with no cache to wait out.
Keeping secrets safe
- Put keys in environment variables or a secrets manager, never in source or client-side code. A browser app should call your own backend, which holds the key.
- Use a separate key per deployment, with a credit cap sized to what that deployment should ever spend.
- Prefer
allowed_modelson keys that only need one model: a leaked key then cannot run up a bill on a pricier route.
Control plane sessions
The control plane API (organisation, keys, provider keys, analytics) authenticates a person, not a service: a sign-in sets two HttpOnly cookies, a 15-minute access token and a 7-day refresh token, and every later call sends them. There is no bearer token for the control plane. The dashboard handles this for you; if you script the control plane yourself, see Auth endpoints for the cookie lifecycle.
Something unclear or wrong on this page? Tell us. Machine-readable copies: llms.txt.