Limits
Rate limits, quota headers, and how to respond to a 429.
This page covers the API rate limits (requests per minute). For per-transaction amount limits by method, see Payment method limits.
Default rate limits
If you exceed these limits, the API responds with HTTP 429 Too Many Requests.
| Endpoint | Limit | Window |
|---|---|---|
POST /process/ | 100 requests | per minute |
GET /transactions/{transaction_id}/ | 300 requests | per minute |
If your application needs higher limits, contact support to discuss your use case.
Rate limit headers
The API includes these headers in every response so you can track your status:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window. |
X-RateLimit-Remaining | Requests remaining in the current window. |
X-RateLimit-Reset | Unix timestamp of when the window resets. |
Handling the 429 error
When you exceed the limit, the API returns HTTP 429 with a body indicating when to retry:
{
"error": {
"code": "rate_limit_exceeded",
"message": "Too many requests",
"retry_after": 60
}
}The retry_after field indicates the seconds to wait before retrying.
Best practices
- Wait at least the
retry_afterseconds before retrying after a429. - Implement exponential backoff for server errors or rate limits.
- Cache responses to avoid repeating requests for the same information (especially
GET). - Control concurrency so parallel requests don't exceed the limit.
Next steps
Was this page helpful?
