Authentication
Every LLMRPM request is authenticated with a single API key, sent as a bearer token. There is no separate credential for the Messages endpoint, no signature scheme, and no per-model key.
Key format
LLMRPM keys are prefixed strings so leaked keys are easy to spot in logs or version control:
LLMRPM stores only a one-way hash of your key. The raw value is shown once, at creation time — copy it immediately, since it cannot be retrieved again afterward.
Creating & revoking keys
Manage keys from /dashboard/api-keys:
- Create. Give the key a name that identifies where it's used (e.g. “prod-backend” or “local-dev”). LLMRPM generates the secret and shows it to you exactly once.
- Revoke. Revoking a key immediately blocks further requests made with it. Requests already in flight are not interrupted, but any new request with a revoked key returns
401. - Rotate. There is no in-place key rotation — create a new key, deploy it, then revoke the old one once traffic has shifted over.
Sending the key
Send your key as a bearer token in the Authorization header on every request — including calls to the Anthropic-format Messages endpoint, which does not use LLMRPM's key in an x-api-key header:
Authorization: Bearer llmrpm_a1b2c3d4e5f6...A missing, malformed, or revoked key returns 401 before your request is routed anywhere — see Errors for the full status code reference.
Anthropic SDK caveat
x-api-key header, not Authorization: Bearer. LLMRPM's Messages endpoint reads the bearer token, so an unmodified Anthropic client pointed at LLMRPM will fail authentication.Both the Node and Python SDKs accept an explicit auth-token override that switches them to bearer authentication — pass your LLMRPM key as authToken (Node) or auth_token (Python) instead of apiKey / api_key. Full working examples are in Messages.
Security practices
- Keep keys server-side. Never ship an LLMRPM key to a browser bundle, mobile client, or public repository — anyone holding it can spend requests from your plan's 5-hour, 24-hour, and 7-day allowances.
- One key per environment. Separate keys for local, staging, and production make it obvious where traffic — and problems — originate, and let you revoke one environment without affecting the others.
- Rotate on exposure. If a key leaks — in a commit, a log line, a client error report — revoke it immediately and issue a new one.
- Verify your email first. Unverified accounts receive
403on every proxied request, even with a valid key.