Skip to main content
This page was last updated on 2 October 2026.

Introduction

To keep latency low and the service reliable for every merchant, the HUB2 API enforces rate limits, with stricter limits on the most resource-intensive endpoints. Unless stated otherwise in the Notes column, limits are counted per client IP address, so one API user’s traffic does not affect another’s.

API limits

The table below lists the endpoint-specific limits. The global limit applies to every endpoint not listed.
Actual limit is the limit as enforced by the API, in requests per time window.
Rationalized limit converts it to requests per minute so that values can be compared on the same scale.
Per :id, Per token and Per merchant limits are counted per resource (and per caller IP for payment intents and tokens), per payment token or per merchant account.
These limits apply to both sandbox and live traffic.
Reduce sandbox traffic if your transaction volume is high.

How to handle limits

When the API receives a request beyond the limit of an endpoint, it rejects it with the HTTP status 429 Too Many Requests and does not process it.
See the MDN documentation for more information about this status.
The following HTTP response headers help you handle limits:

Reactive approach (simpler)

From the client side, the simplest approach is to retry a request after the delay given by Retry-After when it fails with a 429 status:

Proactive approach (more advanced)

The proactive approach consists in keeping a pool of request tokens sized to the rate limit of the target endpoint. Each request consumes a token; when the pool is empty, the next request waits until a token is released. See this article on implementing client-side rate limiting, in particular approaches 4 and 4.1.

Updates

Rate limits prevent abuse and keep the service reliable for everyone. HUB2 continuously works on the stability and performance of the API, and this page is updated whenever limits change.