Rate Limits: Wenn die API die Automati­sierung bremst

Es ist ein typisches Muster: Ein Workflow läuft im Test mit drei Datensätzen tadellos, geht live – und bricht beim ersten großen Durchlauf mit mehreren hundert Datensätzen ab. Schuld ist selten ein Programmierfehler, sondern eine Schutzmaßnahme der Gegenseite: das Rate Limit. Betroffen ist jeder, der aus einer Automatisierung heraus eine externe Schnittstelle aufruft – ein CRM, einen Mailversender, ein Sprachmodell. Ich zeige, woran Sie ein Limit erkennen und wie Sie es in n8n sauber abfangen, statt dagegen anzurennen.

Was ein Rate Limit ist – und warum HTTP 429 auftaucht

Ein Rate Limit ist eine Obergrenze, wie viele Anfragen ein Anbieter pro Zeitfenster zulässt – etwa „60 Aufrufe pro Minute“. Übersteigen Sie diese Grenze, verweigert der Server weitere Anfragen und antwortet mit dem Statuscode 429 Too Many Requests. Die MDN-Referenz beschreibt das als das Signal, dass ein Client „zu viele Anfragen in einem bestimmten Zeitraum“ gesendet hat – das Verfahren dahinter heißt Rate Limiting.

Diese Grenze gilt fast nie global, sondern pro Absender: meist pro API-Schlüssel, manchmal pro IP-Adresse. Das erklärt, warum ein einzelner Testaufruf durchläuft, eine Schleife über 500 Datensätze aber nicht: Erst die Masse in kurzer Zeit reißt das Limit.

Der Retry-After-Header

Viele APIs legen der 429-Antwort einen Retry-After-Header bei. Er sagt konkret, wie lange Sie warten sollen. Laut MDN gibt es dafür zwei Formate: eine Sekundenzahl (Retry-After: 120) oder ein festes Datum (Retry-After: Wed, 21 Oct 2015 07:28:00 GMT). Zusätzlich schicken manche Anbieter Zähler-Header mit, die verraten, wie viele Aufrufe im aktuellen Fenster noch frei sind und wann es zurückgesetzt wird. Die genauen Namen stehen in der jeweiligen API-Dokumentation – die zu lesen ist ohnehin der erste Schritt.

Vorbeugen ist besser als abfangen

Die robusteste Strategie ist, das Limit gar nicht erst zu reißen. Dafür müssen Sie es kennen: Wie viele Anfragen pro Sekunde oder Minute erlaubt die Schnittstelle? Diese Zahl steht in der Doku des Anbieters und ist die Grundlage für alles Weitere. n8n bietet zwei eingebaute Wege, den eigenen Ausstoß zu drosseln; beide sind in der offiziellen Anleitung Handle rate limits beschrieben.

Batching direkt im HTTP Request-Node

Der HTTP Request-Node bringt unter Add Option → Batching zwei Felder mit: Items per Batch legt fest, wie viele Datensätze pro Runde abgeschickt werden, und Batch Interval (ms) bestimmt die Pause zwischen den Runden (0 = keine Pause). Verarbeiten Sie 500 Kontakte und erlaubt die API zwei Anfragen pro Sekunde, halten Sie mit einem Item pro Batch und 500 ms Intervall zuverlässig unter der Grenze. Das ist der einfachste Weg, wenn ohnehin nur ein HTTP-Node die Masse abarbeitet.

Loop Over Items plus Wait-Node

Brauchen Sie mehr Kontrolle – etwa weil zwischen den Aufrufen noch andere Schritte laufen –, nehmen Sie den Loop Over Items-Node (früher Split in Batches). Über den Parameter Batch Size geben Sie ihm eine Portion Datensätze pro Durchlauf; er schickt sie über den loop-Ausgang los und liefert am done-Ausgang das Gesamtergebnis, wenn nichts mehr übrig ist. Hinter den API-Aufruf setzen Sie einen Wait-Node und verbinden ihn zurück zum Loop Over Items. So entsteht eine kontrollierte Schleife mit fester Pause pro Runde – n8n führt genau diesen Aufbau ausdrücklich als Weg auf, Rate Limits zu vermeiden. Laut Doku ist die Batching-Option im HTTP-Node „das Äquivalent zu Loop Over Items und Wait“.

Methode	Wann sie passt
Batching im HTTP Request-Node	Ein Node arbeitet eine Liste ab, simple gleichmäßige Drosselung
Loop Over Items + Wait	Mehrere Schritte pro Runde, dynamische Wartezeit nötig

Wenn das Limit doch greift: Retry mit Wartezeit

Nicht jede Last lässt sich vorhersehen – etwa wenn mehrere Workflows dieselbe API teilen. Für den Fall, dass eine Anfrage doch auf 429 läuft, hat jeder Node im Reiter Settings die Option Retry On Fail: Schlägt der Schritt fehl, wiederholt n8n ihn automatisch. Über Wait Between Tries (ms) bestimmen Sie die Pause dazwischen. Das offizielle Beispiel: Erlaubt die API eine Anfrage pro Sekunde, setzen Sie Wait Between Tries (ms) auf 1000.

Zwei Grenzen sollten Sie dabei kennen, sonst wiegen Sie sich in falscher Sicherheit. Erstens deckelt n8n den eingebauten Retry hart: Max. Tries reicht nur bis 5, Wait Between Tries (ms) nur bis 5000 – höhere Werte werden ohne Warnung auf diese Maxima zurückgesetzt. Fünf Versuche mit je fünf Sekunden fangen einen kurzen Engpass ab, aber kein Limit, das erst in einer Minute wieder öffnet. Zweitens ist die Wartezeit fix: n8n liest den Retry-After-Header nicht von selbst aus und steigert die Pause nicht. Und wer On Error auf eine „Continue“-Option stellt, für den werden Max. Tries und Wait Between Tries sogar ganz ignoriert.

Den Server ernst nehmen: Retry-After und Backoff

Über den eingebauten Retry hinaus gibt es zwei Techniken, die den Unterschied zwischen „läuft meistens“ und „läuft verlässlich“ ausmachen.

Die erste: Nehmen Sie den Retry-After-Header ernst. Der HTTP Request-Node gibt die Antwort-Header mit aus; Sie können den Wert auslesen und per Expression in die Wartezeit eines nachgeschalteten Wait-Nodes schreiben. Dann warten Sie exakt so lange, wie der Anbieter es verlangt – nicht kürzer (sinnlos) und nicht pauschal länger (langsam).

Die zweite: Wenn Sie doch mit festen Wiederholungen arbeiten, lassen Sie die Pause mit jedem Versuch wachsen (exponentieller Backoff) und streuen Sie sie zufällig. Warum die Zufallskomponente? Die AWS-Architekturanalyse zeigt, dass viele Clients mit identischen Backoff-Zeiten synchron erneut zuschlagen – es entstehen „Cluster von Aufrufen“ statt einer gleichmäßigen Last. Erst der sogenannte Jitter, ein zufälliger Anteil in der Wartezeit, verteilt die Wiederholungen so, dass keine neue Welle den Server trifft. n8n bringt das nicht eingebaut mit; wer es braucht, baut die Wartelogik selbst – oder bleibt mit konservativen Stapelgrößen von vornherein unter der Grenze.

Ein API-Limit ist kein Defekt, sondern eine Ansage des Anbieters: so viele Anfragen pro Zeitfenster, mehr nicht. Die robuste Antwort ist deshalb nicht, nach jedem Abbruch schneller nachzufeuern, sondern von vornherein unter der Grenze zu bleiben und die Antwort 429 als Signal zum Bremsen zu behandeln – nicht als seltene Ausnahme.

Drei Fallstricke, die ich immer prüfe

• Wiederholungen erzeugen Duplikate. Ein erneuter Versuch verschickt womöglich dieselbe Mail oder legt denselben Datensatz zweimal an. Wer mit Retries arbeitet, muss die Schritte davor gegen Doppelausführung absichern – wie das geht, steht in Doppelte Aktionen in Automatisierungen verhindern.
• Dauerhafte 429 müssen sichtbar werden. Ein Limit, das nach fünf Versuchen immer noch blockt, ist kein transienter Ausrutscher, sondern ein Betriebsproblem. Es gehört in die Fehlerüberwachung, damit jemand davon erfährt – siehe Wenn die Automatisierung ausfällt: Fehler früh erkennen.
• Polling heizt das Limit an. Wer eine Schnittstelle im Sekundentakt abfragt, verbraucht sein Kontingent für lauter Leerläufe. Oft ist ein Webhook der sparsamere Weg – die Abwägung steht in Webhook oder Polling.

Fazit

Rate Limits sind keine Schikane, sondern der Normalfall bei jeder ernstzunehmenden API. Eine belastbare Automatisierung plant sie ein: Sie kennt die Grenze aus der Doku, bleibt über Batching und Wartezeiten darunter und behandelt eine 429-Antwort als geordnetes Signal zum Nachwarten – nicht als Absturz. Der eingebaute Retry hilft bei kurzen Engpässen, ersetzt aber keine durchdachte Drosselung.

Wenn Sie einen Workflow haben, der unter Last unzuverlässig wird, oder eine Integration planen, die viele Aufrufe erzeugt, schauen wir uns im kostenlosen Prozess-Check gemeinsam an, wo die Limits liegen und wie der Ablauf robust wird. Wie ich Schnittstellen in n8n grundsätzlich anbinde und absichere, beschreibe ich auf der Seite zur n8n-Beratung.