Skip to main content
API keys are how your code talks to the inference API. Each request you send includes a key, and the key tells the platform which workspace the request belongs to, so it is routed and governed by that workspace’s models and policies. Usage is metered and billed at the organization. You manage your keys under Platform > API keys. A key belongs to a workspace, not to you personally. It uses that workspace’s settings, it keeps working when a teammate leaves, and its usage is billed to the organization.

​
The two kinds of key

When you create a key you choose its type. Both kinds are scoped to the workspace you create them in.
  • Full access key. Every ability in the API, within its workspace. Use these for your own backend services. They start with wk_.
  • Restricted key. Limited to the scopes you pick when you create it, for example “Chat completions” or “Read models”. A restricted key can only do what you allowed, so it is the safer choice for a narrow job or a third party. They start with rk_.
Pick the narrowest key that does the job. If a service only needs to list models, give it a restricted key with just that scope.

​
Creating a key

A payment method is required before you can create a key: add one under Billing first. Then click Create key, give it a name you will recognise later (for example “Production server” or “CI”), choose the type, and for a restricted key tick the scopes it should have. The key is created in the workspace you are currently in. The moment the key is created, the full value is shown to you once. Copy it then and store it somewhere safe, like your secret manager. After you close that dialog the full key is gone for good. We only ever keep a masked version (wk_•••• plus the last few characters), so we cannot show it to you again or recover it. If you lose a key, revoke it and create a new one.

​
Using a key

Point your client’s base URL at the inference API and send the key as a bearer token:
Because the API is OpenAI-compatible, most existing tools and SDKs work by changing only the base URL and the key.

​
Revoking a key

If a key leaks, is no longer needed, or belonged to someone who left, revoke it. Find it in the list, choose Revoke, and confirm. Revoking takes effect immediately and cannot be undone, so any service still using that key will stop working at once. Rotating a key is just revoke-the-old, create-a-new.

​
Good to know

You only see the full key once. Right after creation. We store only a masked version, so copy it before you close the dialog. Keys belong to a workspace, and bill to the organization. A key is created in the workspace you are in and is governed by that workspace’s models and policies. What it spends is metered against the organization’s account. The list shows you what each key can do. Its name, type, scope, when it was last used, and who created it, so you can spot a stale or unexpected key. Name your keys well. The name is the only way to tell keys apart later, since the secret part is hidden. A name that says where the key is used makes revoking the right one easy.