Authentication
Two credentials — an API key for machines, a session for the console — and the rules that keep them apart.
Two kinds of credential
The API takes an API key. The console takes a session cookie. They are not interchangeable, and the API enforces that rather than deciding request by request whether a cookie was meant to be there.
A request authenticated with a session cookie gets 403 api_key_required, with a message pointing at the console's key page. This is deliberate: with no cookie-authenticated path into the API, there is nothing for a cross-site request to forge.
The header
Send the key as a bearer token. A key is a prefix, a dot and a secret; the prefix identifies the row, so revocation is immediate and costs one lookup.
curl https://api.llmeu.com/v1/chat/completions \
-H "Authorization: Bearer llmeu_live_xxxxxxxx.your-secret" \
-H "Content-Type: application/json" \
-d '{"model":"llmeu-auto","messages":[{"role":"user","content":"Hello"}]}'Scopes
A key carries one or more scopes. A request whose key lacks the scope an endpoint requires is refused with 403 insufficient_scope, before the body is parsed.
| Scope | Unlocks |
|---|---|
| inference | Chat completions, embeddings, and the model list and detail endpoints. |
| platform_read | Read your organization: profile, keys, usage, traces and policies. |
| platform_write | Create and revoke keys, and create or edit policies. This is the scope that changes who may do what, so mint it deliberately. |
Scopes are checked per endpoint, not per key. A key with platform_read cannot spend credit through the playground.
Creating a key
In the console, or over the platform API with a key that already carries platform_write. The secret is shown once, when it is created: only a scrypt hash is stored, so nobody — including us — can read it back.
curl -X POST https://api.llmeu.com/platform/v1/api-keys \
-H "Authorization: Bearer llmeu_live_xxxxxxxx.a-platform-write-key" \
-H "Content-Type: application/json" \
-d '{"name":"ci","scopes":["inference"]}'Administrative actions in the console — policies, team, settings, credit, revoking keys — are owner or admin only, whatever scopes a key carries.
Revocation, and what a key is not
A key belongs to an organization, and the organization is resolved from the key itself — never from a field in the request body, so a caller cannot address another tenant by asking nicely. Revocation takes effect on the next request. Rotating means creating a second key, moving traffic, then revoking the first; there is no overlap window to configure.
For the console instead
Sign-in, password recovery and address verification are documented with the console. There is no OAuth, no SAML and no personal access token: the console uses a session cookie, the API uses keys.