Authentication

Bearer keys

Authorization: Bearer lib_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 wallet signature (free, no transaction: the server sends a one-time challenge and you sign it), or an email and password. Either one creates the account on the Free plan the first time it is used. Passwords are stored as argon2id hashes, never recoverable, and there is no reset flow yet, because we do not send mail; a forgotten password means writing to support@lcx.com. The wallet path has nothing to forget.

A key that is present but does not resolve returns 401. It is never downgraded to the anonymous tier, because a revoked or mistyped key that quietly keeps working at the keyless rate shows up later as unexplained rate limiting rather than as the auth bug it is.

The anonymous tier

The anonymous tier is served on https://dex-api.lcx.com, not on https://swap-api.lcx.com. The commercial host answers every keyless request with 401 API_KEY_REQUIRED, so pointing an unauthenticated call at it fails whatever the tier allows. Which host you send to is the whole difference.

Requests without a key are served at 5 requests/second per IP with no monthly quota. We cannot attribute an IP to an account, so a monthly counter would be meaningless and would eventually lock out a NAT'd office for reasons nobody could diagnose. Rate limiting alone bounds it.

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