Cette page a été mise à jour le 2 octobre 2026.
Introduction
Afin de garantir un temps de réponse faible et un service fiable pour chaque marchand, l’API HUB2 applique des limites de flux, plus strictes sur les points de terminaison les plus coûteux en ressources. Sauf mention contraire dans la colonne Notes, les limites sont comptées par adresse IP du client : le trafic d’un utilisateur de l’API n’a donc pas d’impact sur celui d’un autre.Limites de l’API
Le tableau ci-dessous liste les limites propres à certains points de terminaison. La limite globale s’applique à tous les points de terminaison non listés.La limite réelle est la limite appliquée par l’API, en nombre de requêtes par fenêtre de temps.
La limite convertie l’exprime en requêtes par minute pour comparer les valeurs sur une même échelle.
Les limites par :id, par jeton et par marchand sont comptées par ressource (et par IP de l’appelant pour les intentions de paiement et les jetons), par jeton de paiement ou par compte marchand.
La limite convertie l’exprime en requêtes par minute pour comparer les valeurs sur une même échelle.
Les limites par :id, par jeton et par marchand sont comptées par ressource (et par IP de l’appelant pour les intentions de paiement et les jetons), par jeton de paiement ou par compte marchand.
Gérer les limites
Lorsque l’API reçoit une requête au-delà de la limite d’un point de terminaison, elle la rejette avec le statut HTTP429 Too Many Requests et ne la traite pas.
Consultez la documentation MDN pour en savoir plus sur ce statut.
Approche réactive (plus simple)
Côté client, l’approche la plus simple consiste à relancer une requête après le délai indiqué parRetry-After lorsqu’elle échoue avec un statut 429 :
