Authentication

Bearer keys

Authorization: Bearer lbk_live_…

That is the whole scheme. No OAuth flow, no request signing, no session to refresh.

Keys come from the dashboard, and the account behind them opens two ways: a six-digit code sent to your email, or Google. Both prove an email address, and the address is the account: the first sign-in creates it on the Free plan, and a later one by the other way reaches the same account. There is no password to store or to forget. A wallet does not open an account; it is what pays for a plan, not who you are.

A key that is present but does not resolve returns 401. It is never treated as if no key had been sent, because a revoked or mistyped key that quietly keeps working shows up later as unexplained rate limiting rather than as the auth bug it is.

Requests without a key

Every call needs a key, including the first one. A request without one is answered with 401 API_KEY_REQUIRED and a link to create a key, which takes about a minute and is free.

Only GET /health and GET /ready answer without one, so an uptime monitor needs no account. /v1/chains, /v1/plans and /v1/usage need a key but never count against your monthly calls.

Pin a key to an origin or IP

In the dashboard under API keys, a key can be restricted to a set of browser origins or server IPs. A pinned key that leaks is worthless to whoever took it, which is the difference between an incident and a rotation.

• Browser keys should always be pinned to an origin. A key shipped in frontend JavaScript is public by construction.
• Server keys should be pinned to an IP where your egress address is stable.

When auth fails