Get started
Authentication
Authenticate with a secret key, and give each key only the access it needs.
Bearer keys
Send your secret key in the Authorization header of every request:
Authorization: Bearer dk_live_…
Keys start with dk_live_ , so a leaked one is easy to spot and to scan for. Requests without a valid key get a 401 . A key belongs to one organization: what it spends comes from that organization's balance.
Permissions
A key can be given All access, Read only access, or a Restricted mix: a level for each service.
Permission
Levels
Lets the key
List the models it can call.
Run models: chat, images, audio, video, embeddings, decisions and reranking.
Read: list and inspect. Write: create, start, stop, delete and run commands.
Read: list and download. Write: upload and delete.
Read spend, request counts and the balance.
A request outside the key's permissions gets a 403 and costs nothing.
Limits on a key
•
Monthly spend cap, in dollars: the key stops working for the rest of the month once it has spent this much.
•
Requests per minute: slows a runaway loop before it costs you.
•
Allowed models: restrict a key to the models it should use.
•
Expiry: the key stops working on a date you choose.
See
Limits for how each one is reported.
Keeping keys safe
•
Call the API from your server. Never put a secret key in a web page, a mobile app or a public repository.
•
Use one key per service or environment, so you can revoke one without breaking the others.
•
Give each key only the permissions it needs, and a spend cap.
•
Rotate keys: create the new one, deploy it, then revoke the old one.
•
If a key leaks, revoke it in the console. It stops working immediately.