Cette documentation a été mise à jour le 21/11/23.

​
Introduction

Puisque son API est le produit phare de Hub2, une qualité de service importante est nécessaire. Afin d’assurer un temps de réponse correct et une continuité des services, certaines limites doivent être appliquées sur les points d’entrée les plus coûteux en ressources. Cette limite est appliquée par adresse IP, elle est donc propre à chaque utilisateur de l’API et l’utilisation d’un client A n’impactera pas l’utilisation d’un client B. C’est d’ailleurs en ce sens que ces limites sont établies.

​
Limitations de l’API

Ci-après un tableau récapitulatif des limites en place. La limite globale s’applique à toutes les autres routes.
GET/transfers1 req / 30 sec2 req / min
POST/transfers75 req / 10 sec400 req / min
GET/transfers/:id1 req / 5 sec12 req / min*per :id
GET/transfers/:id/balance1 req / 10 sec6 req / min
GET/transfers/:id/status5 req / 5 sec60 req / min*per :id
GET/payments1 req / 30 sec2 req / min
GET/payments_intents1 req / 30 sec2 req / min
POST/payments_intents75 req / 10 sec400 req / min
GET/payments_intents/:id1 req / 5 sec12 req / min*per :id
POST/payments_intents/:id/authentication30 req / 5 sec360 req / min
POST/payments_intents/:id/payments75 req / 10 sec400 req / min
POST/payments_intents/:id/payments/sync75 req / 10 sec400 req / min
GET/payments_intents/:id/payment-fees75 req / 10 sec450 req / min
GET/payments/:id/status5 req / 5 sec60 req / min*per :id
GET/payments_intents/:id/status5 req / 5 sec60 req / min*per :id
POST/terminal/payments5 req / 10 sec30 req / min
GET/terminal/payments/:id5 req / 10 sec30 req / min
GET/balance75 req / 10 sec450 req / min
**50 req / 5 sec600 req / minGlobal limit
La limite réelle correspond à la valeur de comment le code réagit en termes de requêtes / secondes.
La limite convertie facilite la compréhension et aide à comparer les valeurs sur une même échelle.
Cette limite s’applique autant au trafic en mode sandbox qu’au trafic en mode live.
Pensez à arrêter le trafic sandbox si le flux devient important.

​
Comment gérer les limites

À chaque fois que l’API reçoit une requête au delà de la limite d’un point de terminaison, une erreur Too Many Requests avec le statut HTTP 429 sera retournée.
Veuillez consulter la documentation MDN à ce sujet.
La requête échoue et ne sera pas traitée par l’API à cause de la limite de flux. Des en-têtes sont fournis dans la réponse HTTP en cas de limitation:
En-têteDescription
Retry-AfterEn cas de limite atteinte,
cet en-tête fournit le temps à attendre avant la prochaine requête
X-RateLimit-LimitLimite en place sur le point de terminaison
X-RateLimit-RemainingNombre de requêtes encore possible avant d’atteindre la limite
X-RateLimit-ResetTemps restant avant qu’une nouvelle requête puisse être faite

​
Solution réactive (plus facile)

Une façon de gérer les limites de flux d’un point de vue client consiste à relancer les requêtes si elles échouent avec un code 429 : 
const MAXIMUM_TRY_COUNT = 3;
const URL = 'https://api.hub2.io/balance;
const CONFIGURATION = {
  method: "GET",
  headers: {
    ApiKey: MY_API_KEY,
    MerchantId: MY_MERCHANT_ID,
  },
};

(function requestRetry(numberOfTries) {
  fetch(URL, CONFIGURATION)
    .then(() => {
      // code here
    })
    .catch((error) => {
      if (error?.response?.status === 429) {
        if (numberOfTries > MAXIMUM_TRY_COUNT) {
          throw error;
        }

        // Adding 1 second of grace delay
        const retryAfter: number = parseInt(response.headers['retry-after'], 10) + 1;
        await new Promise((resolve) => setTimeout(resolve, retryAfter));
        return requestRetry(numberOfTries + 1);
      }
    })
})(0);

​
Solution pro-active (plus compliquée)

La solution proactive est plus délicate, elle consiste à préparer une quantité de requêtes prêtes dans un tableau, autant que la limite de flux de la destination. Lorsque le tableau est vide, alors la prochaine requête attend en ligne d’avoir une place qui se libère. Veuillez consulter cet article intéressant sur comment implémenter la gestion de la limite de flux côté client, particulièrement les approches 4 et 4.1.

​
Conclusion

Dans un monde parfait, il n’y aurait aucune limite de flux. Toutefois dans le monde réel, cela aide à empêcher les abus et à maintenir un service stable pour chacun. L’équipe travaille de manière journalière pour améliorer la stabilité et les performances de l’API et cette page sera aussitôt mise à jour dès lors que des améliorations permettent de relâcher les limites.