Rate limits

Ledgerline limits how fast you can call the API so one noisy integration cannot slow down everyone else. The default limit is 600 requests per minute per API key. This page covers how the limit is measured, how to read your remaining budget and how to recover when you hit it.

The limits

The limits are the same on every plan and in the sandbox. Scale customers can ask for higher per-key and per-organization limits through a support ticket. Plan details are in Plans and pricing.

A sliding window means the count covers the previous 60 seconds at the moment of each request, not a fixed clock minute. You cannot reset your budget by waiting for the top of the minute.

Every request counts as one, whether it succeeds or fails. Requests rejected with a 429 do not count against you again.

Rate limit headers

Every response includes the current state of the most restrictive limit that applies to the request.

HTTP/1.1 200 OK
Ledgerline-RateLimit-Limit: 600
Ledgerline-RateLimit-Remaining: 412
Ledgerline-RateLimit-Reset: 1760000042

When you are throttled

Once the window is full, the API answers with HTTP 429 and the error code rate_limit_exceeded. The response includes a Retry-After header with the number of seconds to wait.

{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded",
    "message": "Rate limit of 600 requests per minute exceeded for this API key.",
    "request_id": "req_01JA2M8ZQX"
  }
}

Treat 429 as a signal to slow down, not as a failure. A 429 is never cached against an idempotency key, so retrying the same request with the same key is safe.

Staying under the limit

• Use webhooks, not polling. Subscribe to payout.paid instead of calling GET /v1/payouts/{id} every few seconds. See the webhooks overview.
• Batch writes. POST /v1/transactions/batch accepts up to 500 transactions in one request.
• Page efficiently. Request limit=100 rather than the default of 25 when you export lists.
• Spread load across keys deliberately. Each key has its own 600-per-minute budget, but the organization-wide cap of 3,000 still applies, so adding keys does not raise the total beyond that.
• Cache reference data. Counterparties and accounts change rarely and are good candidates for short-lived caches.

Backing off correctly

Honor Retry-After first. When it is absent, use exponential backoff with jitter. The recommended schedule and the full list of retryable errors are in Retries and backoff. The official SDKs already do this and retry rate-limited requests up to twice by default.

Limits are not quotas

Rate limits control speed. Quotas control how many resources you may hold, such as ledgers or webhook endpoints. Quotas are listed in Limits and quotas.