How rate limits work
Rate limits are applied per API key within a 60-second rolling window. Limits are organized into tiers based on operation type — more sensitive operations (such as payment creation) have stricter limits, while high-volume read and write operations have more generous allowances. Each tier tracks its own counter independently, so usage against one tier does not affect your capacity in another. When a rate limit is exceeded, requests matching that tier are blocked for 60 seconds, after which requests are automatically accepted again.The same rate limits apply across all environments (Development, Sandbox, and Production).
Rate limits encountered during testing in Development or Sandbox reflect the same thresholds
your integration will experience in Production.
Rate limit tiers
Standard write operations are further divided into independent buckets by resource and
operation type — for example, account creation and entity creation each have their own
6,000 rpm allowance and do not compete with each other.
Rate limit response
When rate limited, the API returns an HTTP429 status code with the following response body:
Handling rate limits
When you receive a429 response, the block lasts for 60 seconds. Retrying immediately
will not succeed. We recommend the following approach:
- Wait at least 60 seconds before retrying the request.
- Use exponential backoff with jitter if subsequent attempts are still rate limited. Add randomness to retry intervals to prevent multiple clients from retrying in sync.
- Combine with idempotency keys on
POSTrequests to ensure retried requests are not processed more than once.
If your integration regularly approaches rate limits, consider spreading requests over time
rather than sending them in bursts. Smoothing traffic reduces the chance of hitting tier
limits during peak operations.