/v1/models.
The header
/v1/messages the Anthropic-style header is accepted instead, so an Anthropic SDK
works without touching its auth code:
Where keys come from
Keys are created in the console under API Keys, and belong to an account. A key looks likemk-prod- followed by 32 random characters.
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: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 a403:
The split between the first two 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.
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.