Rate limits

Infinity limits each API key to 20 requests per second, with bursts of up to 40. The limiter is a token bucket: unused capacity accumulates up to the burst size, so short spikes are absorbed while sustained traffic is held to the steady rate. The sandbox enforces the same limits as live, so load behaviour you see in testing carries over to production.

When you exceed the limit

The request fails with 429 and a Retry-After header giving the number of seconds to wait:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
Request-Id: req_4f4b2bjc4mamxuxm

{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limited",
    "message": "Too many requests. Retry after 1 second.",
    "param": null,
    "request_id": "req_4f4b2bjc4mamxuxm",
    "timestamp": "2026-10-29T10:00:00Z"
  }
}

A rate-limited request isn’t processed, so it’s always safe to retry. Wait at least Retry-After seconds, add jitter so concurrent workers don’t retry in lockstep, and keep the same Idempotency-Key on creates.

Staying within the limit

Create payouts in bulk. One POST /payouts request creates up to 100 payouts.
Use webhooks instead of polling. Infinity notifies you of every status change, so you don’t need to check payouts repeatedly.
Page with limit=100. Fewer, larger pages reduce request count.
Smooth background jobs. Spread scheduled syncs over time rather than issuing them all at once.
Back off on 429. Immediate retries keep you over the limit and extend the throttling.

If your workload needs a higher limit, contact your Infinity team with your expected request volume.

Get started

Concepts

Build reliably

When you exceed the limit

Staying within the limit