Wie Sie n8n-Workflows mit Wait-Node, Batching, Retry on Fail und Pagination robust gegen 429-Fehler absichern.
Wer eigene Workflows gegen Drittanbieter-APIs baut, stößt früher oder später auf die 429-Antwort: „Too Many Requests". Gerade bei Massenverarbeitung, etwa beim Anreichern von hunderten CRM-Kontakten oder beim Synchronisieren großer Produktkataloge, ist das kein Ausnahmefall, sondern die Regel. n8n bringt dafür mehrere eingebaute Werkzeuge mit, die sich kombinieren lassen: den Wait-Node, die Retry-on-Fail-Einstellung im HTTP-Request-Node, das Batching und die Pagination-Steuerung. Stand: Juli 2026.
Der Trick ist nicht, ein einzelnes Feature zu finden, das Rate-Limits „löst", sondern die richtige Kombination für den jeweiligen Anwendungsfall zu wählen. Ein einzelner API-Call mit gelegentlichem Fehlschlag braucht etwas anderes als eine Schleife über zehntausend Datensätze. Im Folgenden gehen wir beide Szenarien durch, orientiert an der offiziellen n8n-Dokumentation.
Laut der n8n-Dokumentation zu Rate-Limits meldet ein Dienst zu viele Anfragen typischerweise mit dem HTTP-Statuscode 429 und der Fehlermeldung, dass der Dienst „zu viele Anfragen von Ihnen" erhält. Diese Meldung taucht im Node-Output auf, wenn eine Anfrage fehlschlägt, und ist der erste Hinweis darauf, dass nicht die Anmeldedaten oder die URL falsch sind, sondern schlicht zu viele Requests in zu kurzer Zeit rausgehen. Wichtig für die Fehlersuche: Ein 429 kann auch mitten in einem Workflow auftreten, der vorher hundertfach fehlerfrei lief, etwa weil ein Drittanbieter sein Limit während einer Kampagne oder eines Traffic-Peaks kurzfristig verschärft. Wer öfter mit derselben API arbeitet, sollte deren Rate-Limit-Dokumentation kennen, bevor der Workflow in Produktion geht.
Für Workflows mit gelegentlichen, nicht systematischen 429-Fehlern reicht oft die eingebaute Wiederholungslogik im HTTP-Request-Node. In den Node-Settings aktivieren Sie Retry On Fail und stellst zwei Werte ein:
Laut der Dokumentation zu häufigen Problemen des HTTP-Request-Node sollten Sie, wenn Sie dieses Setting gezielt gegen Rate-Limits einsetzen, Wait Between Tries (ms) auf einen Wert setzen, der über dem Limit des Dienstes liegt. Erlaubt eine API zum Beispiel eine Anfrage pro Sekunde, stellen Sie 1000 Millisekunden ein, damit der zweite Versuch nicht wieder ins selbe Limit läuft. Der Vorteil dieser Methode: Sie ist mit wenigen Klicks im selben Node erledigt, ohne zusätzliche Nodes im Canvas. Der Nachteil: Bei sehr vielen Items in einer Schleife multipliziert sich die Wartezeit schnell, und ohne zusätzliche Steuerung feuert n8n weiterhin so viele Anfragen wie möglich ab, bevor der erste Fehler überhaupt zurückkommt.
Wenn Sie von vornherein wissen, dass eine API strikte Limits hat, ist es sinnvoller, die Anfragerate präventiv zu steuern statt nur auf Fehler zu reagieren. Dafür bietet der HTTP-Request-Node unter Add Option > Batching zwei Einstellungen:
Laut Dokumentation entspricht diese Batching-Option funktional der Kombination aus Loop Over Items und Wait-Node, nur eingebaut in einen einzigen Node. Wollen Sie zum Beispiel eine Anfrage pro Sekunde an einen Dienst schicken, setzen Sie Batch Interval (ms) auf 1000. Bei APIs mit Limits pro Minute statt pro Sekunde rechnen Sie entsprechend um, etwa 60 Anfragen pro Minute ergeben ein Intervall von 1000 Millisekunden zwischen Einzel-Requests oder ein größeres Intervall bei mehreren Items pro Batch. Für Massenverarbeitung ist das die robustere Grundeinstellung, weil sie das Problem an der Wurzel angeht, statt erst nach einem Fehlschlag zu reagieren.
Für Fälle, in denen Sie zwischen den Batches noch eigene Logik brauchen, etwa ein Logging, eine bedingte Verzweigung oder ein dynamisches Anpassen der Wartezeit je nach Antwort, kombinieren Sie Loop Over Items mit einem eigenen Wait-Node. Der Aufbau: Loop Over Items vor dem API-Call platzieren, danach den Wait-Node einfügen und dessen Ausgang zurück auf Loop Over Items verbinden. So entsteht eine Schleife, die nach jedem Batch oder jedem einzelnen Item bewusst pausiert, bevor die nächste Runde losläuft.
Der Wait-Node selbst ist laut der n8n-Dokumentation zum Wait-Node dafür gemacht, eine laufende Ausführung anzuhalten und mit denselben Daten dort fortzusetzen, wo sie unterbrochen wurde. Für das Thema Rate-Limits ist vor allem der Modus After Time Interval relevant: Sie geben eine Zeitspanne in Sekunden, Minuten, Stunden oder Tagen an, und der Workflow pausiert exakt so lange. Wichtig zu wissen: Bei Wartezeiten unter 65 Sekunden lagert n8n die Ausführungsdaten nicht in die Datenbank aus, die Pause läuft also leichtgewichtig im Arbeitsspeicher. Bei längeren Wartezeiten übernimmt n8n das Zwischenspeichern automatisch, was den Workflow auch über Neustarts der Instanz hinweg zuverlässig fortsetzbar macht. Neben After Time Interval unterstützt der Node auch At Specified Time, On Webhook Call und On Form Submitted, die für andere Szenarien wie externe Freigaben oder geplante Ausführungen gedacht sind, für reines Rate-Limiting aber selten gebraucht werden.
Ein häufiger Grund für Rate-Limit-Fehler ist gar nicht die Frequenz der Anfragen, sondern deren Menge: Wer versucht, zehntausend Datensätze in einem einzigen ungebremsten Durchlauf zu paginieren, produziert in kurzer Zeit sehr viele Requests hintereinander. Laut der n8n-Dokumentation zur Pagination unterstützt der HTTP-Request-Node dafür unterschiedliche Modi:
{{ $response.body["next-page"] }}.{{ $pageCount + 1 }} für eine bei null beginnende Zählung, die auf eine bei eins beginnende API-Paginierung abgestimmt werden muss.Die Dokumentation weist ausdrücklich darauf hin, dass jede API Pagination anders umsetzt. Sie sollten deshalb vorher prüfen, ob der Dienst mit Next-URLs, mit Seitenzahlen oder mit Offset-Parametern arbeitet, und wie viele Ergebnisse pro Seite maximal erlaubt sind. Die Seitengröße legen Sie meist über einen eigenen Query-Parameter wie limit in den Node-Einstellungen fest. Kombinieren Sie Pagination mit Batching oder einem Wait-Node zwischen den Seitenabrufen, verhindern Sie, dass ein umfangreicher Datenexport allein durch seine Geschwindigkeit gegen das Limit läuft, noch bevor die eigentliche Verarbeitung beginnt.
Für die Praxis lohnt sich eine grobe Einordnung, welches Werkzeug wann greift:
In der Praxis reicht selten ein einzelnes Werkzeug für einen kompletten Workflow. Ein typisches Muster ist Pagination für den Datenabruf, ein moderates Batch-Intervall während der Verarbeitung und zusätzlich Retry On Fail als Sicherheitsnetz für die Momente, in denen selbst die gedrosselte Rate noch zu einem vereinzelten 429 führt. Sie behalten so die Kontrolle über Tempo und Zuverlässigkeit Ihres Workflows, statt sich auf das Glück zu verlassen, dass der Drittanbieter nie unter Last gerät.
Retry On Fail reagiert erst, nachdem eine Anfrage bereits fehlgeschlagen ist, und wiederholt sie nach einer festgelegten Wartezeit. Batching setzt vorher an und drosselt von Anfang an, wie viele Anfragen in welchem Abstand überhaupt rausgehen. Für bekannte, feste Limits ist Batching die sauberere Lösung, für gelegentliche unvorhersehbare Fehlschläge ergänzt Retry On Fail das Ganze als Absicherung.
Laut n8n-Dokumentation lagert der Wait-Node Ausführungsdaten erst bei Wartezeiten ab 65 Sekunden in die Datenbank aus. Kürzere Pausen laufen leichtgewichtig ohne diesen Zwischenschritt, was für die meisten Rate-Limit-Szenarien mit Sekundenbruchteilen bis wenigen Sekunden Pause ausreicht.
Ja, das ist sogar ein gängiges Muster. Batching im HTTP-Request-Node deckt die laufende Drosselung während der eigentlichen Verarbeitung ab, ein zusätzlicher Wait-Node kann an anderer Stelle im Workflow eine gezielte, längere Pause einbauen, etwa zwischen einzelnen Seitenabrufen bei der Pagination oder vor einem besonders limitierten Folge-Schritt.
Starten Sie konservativ mit einem größeren Intervall, etwa 1000 bis 2000 Millisekunden zwischen Anfragen, und beobachten Sie, ob weiterhin 429-Fehler auftreten. Viele APIs geben das Limit auch in Response-Headern an, die Sie im HTTP-Request-Node auswerten und für eine dynamische Anpassung der Wartezeit nutzen können. Zusätzlich hilft ein aktiviertes Retry On Fail als Sicherheitsnetz, falls die Schätzung anfangs zu knapp war.
Nicht zuverlässig. Retry On Fail wiederholt einzelne fehlgeschlagene Anfragen, verhindert aber nicht, dass n8n bei einer großen Schleife ohne Batching viele Anfragen kurz hintereinander abschickt. Bei hohem Volumen ist die Kombination aus Batching oder Loop Over Items mit Wait-Node die robustere Wahl, Retry On Fail bleibt dabei sinnvoll als zusätzliche Absicherung.
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
Wie n8n Items automatisch durchläuft, wie der Loop Over Items Node arbeitet und welche Batch-Größe für Performance und Rate-Limits sinnvoll ist.
Error Workflows, Retry On Fail und Teams-Benachrichtigungen: So bauen Sie zuverlässiges Error Handling in n8n auf.
Retry on Fail, Batching, Wait-Node und Pagination lassen sich einzeln nutzen, entfalten ihre Wirkung aber erst in der richtigen Kombination. NordFlux baut Ihre n8n-Integrationen so, dass sie Rate-Limits von APIs von Anfang an berücksichtigen, statt nach dem ersten Ausfall nachzubessern. Im ersten Gespräch schauen wir uns Ihre kritischen Schnittstellen an.