Rate limit : définition, HTTP 429 et Retry-After
Un rate limit est une limite imposée aux requêtes : nombre d’appels par minute, par heure, par compte, par IP ou par endpoint. Quand vous dépassez la limite, le serveur peut répondre 429 Too Many Requests. RFC 6585 définit ce statut.
Retry-After
Un serveur peut envoyer l’en-tête Retry-After pour indiquer combien de temps attendre. La valeur peut être un nombre de secondes ou une date HTTP selon le contexte. Si l’en-tête existe, respectez-le. Sinon, utilisez un backoff progressif et un nombre d’essais limité.
Exemple n8n ou script
Si une API renvoie 429, n’enchaînez pas dix retries immédiats. Attendez, puis reprenez depuis le dernier item traité. Combinez batch de 1, Wait et checkpoint pour ne pas perdre la position.
Ce qu’il faut compter
- Succès.
- 429.
- Erreurs réseau.
- Échecs définitifs.
- Items reportés.
Sans compteur, vous ne savez pas si le workflow ralentit proprement ou s’il abandonne silencieusement des données.
Décision pratique
Dimensionnez le workflow à partir de la limite la plus basse, pas de la moyenne observée. Si l’API autorise 60 appels par minute, ne programmez pas 60 appels parfaits : gardez une marge, par exemple 45, puis mesurez. Pour les imports longs, ajoutez un compteur persistant afin de savoir combien d’items restent à traiter après une pause imposée par le fournisseur.
À ne pas confondre
Un rate limit n’est pas une panne et n’est pas forcément une sanction. C’est souvent une règle normale de protection du service. Une erreur 401 demande de vérifier l’authentification. Une erreur 403 demande de vérifier les droits. Une erreur 429 demande surtout de ralentir, de relancer plus tard ou de demander un quota supérieur.
Formule simple
Cadence sûre = limite officielle moins marge de sécurité. Si le fournisseur annonce 100 appels par minute, commencez à 70 ou 80, observez les 429, puis ajustez. Pour plusieurs workflows qui partagent la même clé, la limite est commune : deux scénarios séparés peuvent se bloquer mutuellement.
Signal d’alerte
Si les 429 augmentent sans hausse de volume, vérifiez si un autre workflow utilise la même clé ou si le fournisseur a réduit le quota. Le problème peut venir de votre cadence, mais aussi d’une limite partagée ou modifiée.
Une limite peut être partagée
Deux workflows utilisant la même clé peuvent consommer le même quota. Ralentir un seul workflow ne suffit alors pas : surveillez l’ensemble des appels du compte et réduisez leur concurrence. Une limite peut également porter sur les tokens ou un volume de données, pas uniquement sur le nombre de requêtes.
Un exemple fictif de réponse Retry-After: 30 demande d’attendre trente secondes. Une valeur sous forme de date HTTP indique un instant à partir duquel reprendre. Cet en-tête est facultatif dans une réponse 429 : son absence n’autorise pas une relance immédiate en boucle.
Relancer sans créer deux opérations
Prévoir un délai ne résout pas les doublons métier. Pour un appel d’écriture dont l’issue est incertaine, contrôlez l’identifiant de l’opération et le mécanisme d’idempotence du fournisseur. Après un nombre borné de tentatives, placez la demande en attente ou demandez une intervention, au lieu d’accumuler des appels sans fin. Une limite de débit n’est pas une preuve que l’abonnement est trop petit.