API-Rate-Limits behandeln: Wait, Batching, Retry, Pagination

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.

Woran erkennt man ein Rate-Limit-Problem

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.

Retry on Fail: Einzelne Anfragen automatisch wiederholen

Für Workflows mit gelegentlichen, nicht systematischen 429-Fehlern reicht oft die eingebaute Wiederholungslogik im HTTP-Request-Node. In den Node-Settings aktivierst Du Retry On Fail und stellst zwei Werte ein:

• Max Tries legt fest, wie oft n8n die Anfrage nach einem Fehlschlag maximal erneut versucht.
• Wait Between Tries (ms) bestimmt die Pause zwischen den Versuchen in Millisekunden.

Laut der Dokumentation zu häufigen Problemen des HTTP-Request-Node solltest Du, wenn Du dieses Setting gezielt gegen Rate-Limits einsetzt, Wait Between Tries (ms) auf einen Wert setzen, der über dem Limit des Dienstes liegt. Erlaubt eine API zum Beispiel eine Anfrage pro Sekunde, stellst Du 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.

Batching im HTTP-Request-Node: Requests bewusst drosseln

Wenn Du von vornherein weißt, 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:

• Items per Batch: Wie viele Input-Items pro Anfrage-Runde verarbeitet werden.
• Batch Interval (ms): Die Pause zwischen den Batches in Millisekunden.

Laut Dokumentation entspricht diese Batching-Option funktional der Kombination aus Loop Over Items und Wait-Node, nur eingebaut in einen einzigen Node. Willst Du zum Beispiel eine Anfrage pro Sekunde an einen Dienst schicken, setzt Du Batch Interval (ms) auf 1000. Bei APIs mit Limits pro Minute statt pro Sekunde rechnest Du 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.

Loop Over Items und Wait-Node: Volle Kontrolle über den Rhythmus

Für Fälle, in denen Du zwischen den Batches noch eigene Logik brauchst, etwa ein Logging, eine bedingte Verzweigung oder ein dynamisches Anpassen der Wartezeit je nach Antwort, kombinierst Du 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: Du gibst 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.

Pagination sauber steuern, statt alles auf einmal zu laden

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 Contains Next URL: Die API liefert in ihrer Antwort direkt die URL der nächsten Seite, die Du per Ausdruck ausliest, etwa `{{ $response.body["next-page"] }}`.
• Update a Parameter in Each Request: Du erhöhst selbst einen Query- oder Body-Parameter zwischen den Anfragen, zum Beispiel mit `{{ $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. Du solltest 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 legst Du meist über einen eigenen Query-Parameter wie `limit` in den Node-Einstellungen fest. Kombinierst Du Pagination mit Batching oder einem Wait-Node zwischen den Seitenabrufen, verhinderst Du, dass ein umfangreicher Datenexport allein durch seine Geschwindigkeit gegen das Limit läuft, noch bevor die eigentliche Verarbeitung beginnt.

Praxismuster: Welche Kombination für welchen Fall

Für die Praxis lohnt sich eine grobe Einordnung, welches Werkzeug wann greift:

• Gelegentliche 429-Fehler bei niedrigem Volumen: Retry On Fail mit passendem Wait Between Tries reicht meist aus.
• Bekanntes, festes Rate-Limit bei hohem Volumen: Batching im HTTP-Request-Node mit einem Intervall passend zum Limit des Dienstes.
• Komplexere Logik zwischen den Aufrufen, etwa dynamische Pausen je nach Response-Header oder zusätzliche Verzweigungen: Loop Over Items kombiniert mit einem eigenen Wait-Node.
• Große Datenmengen über mehrere Seiten: Pagination-Modus passend zur API wählen und zusätzlich mit Batching oder Wait entschärfen.

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. Du behältst so die Kontrolle über Tempo und Zuverlässigkeit Deines Workflows, statt Dich auf das Glück zu verlassen, dass der Drittanbieter nie unter Last gerät.

Häufige Fragen

Was ist der Unterschied zwischen Retry On Fail und Batching?

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.

Ab welcher Wartezeit speichert der Wait-Node die Ausführung in der Datenbank?

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.

Kann ich Batch Interval und Wait-Node gleichzeitig im selben Workflow nutzen?

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.

Was mache ich, wenn ich das genaue Rate-Limit einer API nicht kenne?

Starte konservativ mit einem größeren Intervall, etwa 1000 bis 2000 Millisekunden zwischen Anfragen, und beobachte, ob weiterhin 429-Fehler auftreten. Viele APIs geben das Limit auch in Response-Headern an, die Du im HTTP-Request-Node auswerten und für eine dynamische Anpassung der Wartezeit nutzen kannst. Zusätzlich hilft ein aktiviertes Retry On Fail als Sicherheitsnetz, falls die Schätzung anfangs zu knapp war.

Reicht Retry On Fail allein aus, um Rate-Limits bei großen Datenmengen zu vermeiden?

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.