Skip to main content
Every request to the inference API carries an API key. There is no unauthenticated endpoint, not even /v1/models.

​
The header

On /v1/messages the Anthropic-style header is accepted instead, so an Anthropic SDK works without touching its auth code:
Both name the same key. Sending both is fine as long as they match.

​
Where keys come from

Keys are created in the console under API Keys, and belong to an account. A key looks like mk-prod- followed by 32 random characters.
The plaintext is shown once, at creation. We store a hash of it and the first eight characters for display — there is no screen, and no support process, that can recover a key after that. If you lose one, revoke it and create another.
That is the whole reason the snippets on this site read PRENTIS_API_KEY from the environment instead of carrying a key inline: a key that ends up in a repository has to be revoked, and you cannot un-publish it.

​
Revoking

Revocation takes effect for new requests within seconds. A request made with a revoked key gets:
A 401 INVALID_API_KEY is not retryable — nothing about waiting changes it. It is also never billed. In-flight requests are not cancelled by a revocation. If you are revoking a key because it leaked, treat anything already accepted as already served.

​
What a key may do

A key inherits the account it was created in, and the account decides which models it can reach. Asking for a model the account may not use is a 403: A key can also be narrowed when it is created. Models limits it to the models you list. Operations limits it to the kinds of call you tick: chat covers /chat/completions, /messages and /responses; completions covers /completions; training and datasets cover the fine-tuning API. These four lower-case names are the whole list; anything else is refused when the key is saved. Listing models (GET /models, GET /models/{id}) is not an operation and works with any valid key. Leave either list empty and the key is not limited by it. An allowed-IP list can be saved on a key but is not enforced yet, so do not rely on it. The split between the first two codes matters when you are debugging: a 404 means the name is wrong or the model was never available to you; a 403 means the name is right and the permission is not.

​
Keeping keys separate

One key per deployment, rather than one key everywhere, is worth the small amount of extra setup:
  • Revoking a leaked key takes one service offline instead of all of them.
  • Per-request logs in the console show which key made each call, so you can tell staging traffic from production traffic without adding anything to your requests.
If you want to correlate calls with your own users on top of that, send a user field (or metadata.user_id on /v1/messages). It is echoed into this request’s log line and is not kept on the usage record.

​
Next

Rate limits and quotas

What throttles you once the key works.

Errors

Every code, whether to retry it, and whether it is billed.