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.
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.
How to handle limits
When the API receives a request beyond the limit of an endpoint, it rejects it with the HTTP status429 Too Many Requests and does not process it.
See the MDN documentation for more information about this status.
Reactive approach (simpler)
From the client side, the simplest approach is to retry a request after the delay given byRetry-After when it fails with a 429 status:
