Skip to main content
Method enforces rate limits on all API requests to protect platform stability and ensure fair usage across all customers. Rate limits apply to all environments (Development, Sandbox, and Production) and all API versions.

​
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

TierLimit (requests per minute)Description
Payment creation120POST /payments
Critical operations60Payment deletion and report generation
Standard writes6,000Entity and Account operations (create, update, connect, subscriptions)
Other writes1,800All other write operations
Reads6,000All GET requests
Unauthenticated60Per IP address, requests without an API key
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 HTTP 429 status code with the following response body: 
{
  "success": false,
  "data": {
    "error": {
      "type": "INVALID_REQUEST",
      "code": 429,
      "sub_type": "TOO_MANY_REQUESTS",
      "message": "The maximum request limit for this time has been exceeded. Please re-try your request at a later time."
    }
  },
  "message": "The maximum request limit for this time has been exceeded. Please re-try your request at a later time."
}

​
Handling rate limits

When you receive a 429 response, the block lasts for 60 seconds. Retrying immediately will not succeed. We recommend the following approach:
  1. Wait at least 60 seconds before retrying the request.
  2. 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.
  3. Combine with idempotency keys on POST requests 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.

​
Enterprise rate limits

Customers with high-volume integrations can request custom rate limits tailored to their usage patterns. Contact your customer success manager or reach out to our team to discuss enterprise rate limit overrides.