Skip to main content
Ledger limits requests per API key, so one runaway loop can’t slow down everyone else. Each limit is a token bucket: you can send a burst at once, then keep up the sustained rate. Each kind of request has its own budget: billing calls don’t use up a key’s check budget, and sandbox and live keys are counted separately.

​
Headers

Every API response says where the key stands:

​
Handling a 429

Over the limit, Ledger answers 429 with { "error": "rate_limited" } and a Retry-After header in seconds. Nothing was recorded: wait that long and send the same request again. Retrying track with the same request_id is always safe. The SDKs fail open on a 429 from check or track. Spread out bulk work, such as a backfill or a catalog script, rather than sending it all at once. If your traffic needs more than these limits, contact us.

​
Failed requests

Repeated 401 responses from one IP address, about 30 in a row, make Ledger refuse further requests from that address for a short time. A key that has worked recently keeps working. Check your key if you see 401s.

​
Request size

Request bodies are limited to 1 MiB, far more than the largest catalog. A bigger body gets 413 with { "error": "payload_too_large" }.

​
Webhooks

Signed Stripe and Clerk webhook deliveries are never limited. Only deliveries that fail verification count, per sending address and endpoint.