Un workflow n8n tourne sans problème pendant des semaines, puis un lot plus gros que d'habitude passe, et le même nœud s'arrête avec un message : « The service is receiving too many requests from you ». Ce message correspond à une réponse HTTP 429. Le service appelé ne refuse pas vos identifiants : il vous demande de ralentir.
Cet article explique comment lire cette erreur, quelles options n8n propose pour la traiter, et comment choisir entre elles selon votre volume. Les faits sur n8n viennent de sa documentation officielle, citée en fin d'article ; les recommandations sont notre analyse, à adapter à votre contexte.
Ce que signifie une erreur 429
La plupart des API limitent le nombre de requêtes qu'un client peut envoyer sur une période donnée : par seconde, par minute, par jour, parfois en nombre de requêtes simultanées. Au-delà, le service répond par un code 429 (« trop de requêtes ») au lieu de traiter la demande.
Dans n8n, un nœud qui atteint une limite affiche l'erreur dans son panneau de sortie, avec le message renvoyé par le service. La documentation n8n rappelle que les limites exactes dépendent de chaque service : la première étape consiste donc à lire la documentation de l'API que vous appelez pour connaître sa règle (nombre de requêtes, durée de la fenêtre, quotas quotidiens).
Cette distinction compte pour la suite :
- une limite de cadence (par exemple une requête par seconde) se règle en espaçant les appels ;
- un quota quotidien ou mensuel ne se règle pas en attendant quelques secondes : il faut réduire le nombre total d'appels, ou changer de formule auprès du fournisseur.
Pourquoi cela arrive surtout avec des lots
Un workflow qui traite un contact à la fois dépasse rarement une limite. Le problème apparaît quand un nœud reçoit beaucoup d'éléments d'un coup : import de 500 lignes, synchronisation d'un catalogue, relance de toutes les exécutions en échec. Le nœud enchaîne alors les appels aussi vite qu'il le peut.
Un cas fréquent dans les automatisations d'IA : un nœud envoie une requête à un modèle de langage pour chaque ligne d'un tableau. Les fournisseurs de modèles appliquent eux aussi des limites de cadence, et la documentation n8n prend d'ailleurs l'API d'OpenAI comme exemple pour le motif décrit plus bas.
Option 1 : Retry On Fail, pour les dépassements occasionnels
C'est le réglage le plus simple. Dans le nœud, ouvrez Settings, activez Retry On Fail, puis renseignez Wait Between Tries (ms) avec une valeur supérieure à la limite de l'API. L'exemple de la documentation : pour une API qui autorise une requête par seconde, saisissez 1000.
Quand l'utiliser :
- les 429 sont rares ;
- le volume est faible ;
- la limite est courte (par seconde ou par minute).
Ses limites :
- le délai est fixe : n8n ne l'adapte pas à ce que le service demande ;
- le nœud réessaie après l'échec, il ne prévient pas les dépassements : vous continuez à générer des erreurs, simplement absorbées ;
- sur un gros lot, chaque élément peut buter sur la limite et ralentir l'ensemble.
Notre article sur la gestion des erreurs avec l'Error Trigger détaille les autres réglages par nœud et l'alerte en cas d'échec définitif.
Option 2 : Loop Over Items et Wait, pour espacer les appels
Si vous traitez régulièrement des lots, mieux vaut éviter le dépassement plutôt que le réparer. La documentation décrit le motif :
- ajouter un nœud Loop Over Items avant le nœud qui appelle l'API : il découpe les éléments en petits lots ;
- ajouter un nœud Wait après le nœud d'appel, et le reconnecter à Loop Over Items ;
- la boucle traite un lot, attend, puis passe au suivant.
Vous maîtrisez ainsi la cadence : taille du lot et durée de la pause se règlent séparément.
Un point sur le nœud Wait : d'après la documentation, une attente inférieure à 65 secondes laisse le workflow actif sans enregistrer de données d'exécution en base ; au-delà, les données d'exécution sont déchargées dans la base de données, puis rechargées à la reprise. Pour de simples pauses entre requêtes, vous restez dans le premier cas.
Option 3 : l'option Batching du nœud HTTP Request
Le nœud HTTP Request intègre le même mécanisme. Sous Add Option, choisissez Batching et réglez :
- Items per Batch : le nombre d'éléments envoyés dans chaque lot ;
- Batch Interval (ms) : le délai entre deux lots (0 pour aucun délai).
La documentation indique que cette option fait le même travail que Loop Over Items associé à Wait. Elle est plus compacte, mais ne concerne que ce nœud : si l'appel passe par un autre nœud d'intégration, utilisez la boucle.
Nous recommandons de tester avec une taille de lot de 1 quand l'API limite le nombre de requêtes simultanées, pour ne pas envoyer plusieurs requêtes à la fois dans un même lot. C'est une précaution de notre part, pas une règle documentée par n8n.
Quelle option choisir ?
| Situation | Option adaptée |
|---|---|
| 429 occasionnels, faible volume | Retry On Fail avec un délai supérieur à la limite |
| Lots réguliers, API appelée par un nœud HTTP Request | Batching du nœud |
| Lots réguliers, nœud d'intégration, ou besoin de pauses entre étapes | Loop Over Items + Wait |
| 429 constants malgré le ralentissement | Vérifier le quota quotidien ou la limite de simultanéité |
Une méthode pour régler sans deviner
- Lire la limite dans la documentation de l'API : valeur, fenêtre, quotas.
- Reproduire avec un petit lot pour confirmer à partir de quel volume l'erreur apparaît.
- Poser un délai prudent, légèrement supérieur à la limite, plutôt que la valeur exacte : une marge évite les dépassements dus aux écarts de timing.
- Mesurer la durée totale du traitement : un lot de 1 000 éléments à une requête par seconde dure plus de 16 minutes. Vérifiez que cela reste acceptable, et si besoin, déplacez le traitement hors des heures d'usage.
- Alerter en cas d'échec définitif, pour qu'un 429 persistant ne reste pas silencieux.
Quand le ralentissement ne suffit pas
Si vous avez espacé les appels et que les 429 persistent, cherchez ailleurs :
- un quota quotidien atteint : seule la réduction du nombre d'appels ou un changement de formule règle le problème ;
- plusieurs workflows qui partagent la même clé d'API : chacun respecte sa cadence, mais leur somme dépasse la limite ;
- un autre outil qui consomme le même quota que votre automatisation ;
- des exécutions simultanées : si vous passez à l'échelle, le mode queue et les workers multiplient les appels parallèles. Notre article sur le mode queue et les workers explique comment limiter la concurrence.
Pour structurer une automatisation qui appelle plusieurs services, notre article sur les sous-workflows montre comment isoler l'appel à une API dans un bloc réutilisable : la règle de cadence se règle alors à un seul endroit.
Les erreurs fréquentes
- Augmenter le nombre d'essais sans espacer les appels : on aggrave la pression sur le service.
- Confondre limite de cadence et quota quotidien, et régler un problème de volume avec des pauses.
- Oublier les autres consommateurs de la même clé d'API.
- Ne pas tester sur un gros lot avant la mise en production.
- Laisser l'échec définitif sans alerte : le lot est à moitié traité et personne ne le sait.
Besoin d'automatisations qui tiennent la charge ?
Vos workflows n8n échouent dès que le volume augmente ? Décrivez-nous votre situation : nous identifions les appels qui dépassent les limites de vos services, mettons en place une cadence adaptée et ajoutons la surveillance qui manquait. Nos offres détaillent les formats d'accompagnement, et vous pouvez nous contacter directement.
Sources
- n8n, Handle rate limits, documentation consultée le 23 octobre 2026.
- n8n, HTTP Request node : options Batching et Pagination, documentation consultée le 23 octobre 2026.
- n8n, Wait node, documentation consultée le 23 octobre 2026.