FlowAlp

Limites de débit Merchant API

July 30, 2026

Limites de débit de la Merchant API FlowAlp Pay : 600 requêtes par 5 minutes, signaux 405/403 sous charge, stratégie de retry avec backoff.

La Merchant API applique un quota de requêtes afin d'offrir des performances prévisibles à tous les marchands. Concevez votre intégration pour rester bien en dessous de la limite et ralentir proprement lorsqu'elle est atteinte.

La limite

PropriétéValeur
Quota600 requêtes par 5 minutes
PortéeToutes les requêtes Merchant API
ApplicationWeb application firewall à la périphérie de la plateforme (AWS WAF)

Le quota couvre aussi bien les pics que le trafic soutenu : 600 requêtes en cinq minutes correspondent en moyenne à deux requêtes par seconde.

Que se passe-t-il en cas de dépassement

SignalSignificationAction recommandée
405 Method Not AllowedPremier signal typique émis par la périphérie de la plateformeFaire une pause, puis réessayer avec backoff
403 ForbiddenBlocage qui suit tant que la limite reste dépasséeStopper la rafale ; augmenter nettement les délais

Ces deux codes surviennent aussi pour d'autres raisons — mauvais verbe HTTP ou permissions manquantes. Ne les traitez comme signaux de rate limit que lorsqu'ils sont corrélés à un volume élevé ; la sémantique complète des statuts se trouve dans Erreurs Merchant API.

Stratégie de backoff

Réessayez avec un backoff exponentiel et du jitter :

ParamètreValeur suggérée
Délai initial500 ms
Multiplicateur2.0 par tentative
Jitter0–300 ms aléatoires ajoutés à chaque tentative
Délai maximal30 s
Tentatives maximales5
Wrapper de backoff Node.jsJavaScript
async function withBackoff(fn, { maxAttempts = 5, baseMs = 500, maxDelayMs = 30000 } = {}) {
  for (let attempt = 1; ; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const retriable = [403, 405, 429].includes(err.status) || err.status >= 500;
      if (!retriable || attempt >= maxAttempts) {
        throw err;
      }
      const delay =
        Math.min(baseMs * 2 ** (attempt - 1), maxDelayMs) + Math.random() * 300;
      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }
}
Boucle de backoff PHPPHP
<?php
$delayMs = 500;

for ($attempt = 1; $attempt <= 5; $attempt++) {
    [$status, $body] = sendFlowAlpRequest(); // your HTTP call

    if ($status < 400) {
        break;
    }
    if (!in_array($status, [403, 405, 429], true) && $status < 500) {
        throw new RuntimeException('Non-retriable error: HTTP ' . $status);
    }

    usleep(($delayMs + random_int(0, 300)) * 1000);
    $delayMs = min($delayMs * 2, 30000);
}

Réduire votre volume de requêtes

  • Utilisez les webhooks au lieu d'interroger le statut de paiement en boucle.
  • Mettez en cache les données qui évoluent lentement, comme la liste des fournisseurs de PaymentProvider.
  • Agrégez le travail : récupérez des listes en une seule requête plutôt que les entités une par une.
  • Étalez dans le temps les tâches planifiées comme la réconciliation, au lieu de toutes les lancer à l'heure pile.

Ne répondez jamais à un 403/405 par des retries immédiats en boucle serrée — cela maintient le blocage actif. Augmentez toujours le délai entre les tentatives.

Étape suivante : renforcez votre gestion des erreurs avec Erreurs Merchant API et configurez les webhooks.