Rate Limits: warum Ihre Automatisierung leise die Hälfte verliert, sobald es ernst wird
Rate Limits sind der häufigste Grund, warum ein Sync grün meldet und trotzdem Daten fehlen. Wir erklären, was hinter HTTP 429 steckt, warum No-Code-Tools das Problem verschlucken und wie Sie in Make, n8n und Zapier sauber damit umgehen.
Der Sync lief grün, und trotzdem fehlten 600 Kontakte
Vor ein paar Monaten haben wir bei einem Kunden einen nächtlichen Abgleich untersucht, der jeden Morgen brav eine Erfolgsmeldung schickte. Shop-System raus, CRM rein, alle Kontakte, jede Nacht. Auf dem Dashboard stand grün. Trotzdem fehlten im CRM regelmäßig mehrere Hundert Datensätze, mal 300, mal 600, nie dieselben.
Der Kunde hatte die Lücke monatelang von Hand nachgepflegt, weil niemand verstand, woran es lag. Der Workflow sah korrekt aus. Die Logik stimmte. Und genau das war das Tückische: Es war kein Logikfehler. Die API des CRM hatte irgendwann während des Laufs mit einem HTTP 429 geantwortet, "Too Many Requests", und das No-Code-Tool hatte diese Antwort wie einen Erfolg behandelt und war weitergezogen. Die Kontakte, die in diesem Moment dran waren, fielen lautlos hinten runter.
Rate Limits sind in unserer Erfahrung der häufigste Grund, warum eine Automatisierung scheinbar funktioniert und trotzdem Daten verliert. Und fast niemand baut von Anfang an dafür.
Was ein Rate Limit eigentlich ist
Jede API, die etwas taugt, begrenzt, wie viele Anfragen Sie in einem bestimmten Zeitraum stellen dürfen. HubSpot, Salesforce, Stripe, Google, die Schnittstellen sehen unterschiedlich aus, aber das Prinzip ist immer gleich: zu viele Calls in zu kurzer Zeit, und Sie bekommen statt Ihrer Daten den Status 429 zurück.
Das ist kein Defekt, sondern Absicht. Der Anbieter schützt seine Server vor Überlastung und sorgt dafür, dass ein einzelner Kunde nicht die ganze Plattform ausbremst. Viele APIs schicken im Header sogar mit, wie lange Sie warten sollen, bevor Sie es erneut versuchen. Dieses Feld heißt "Retry-After" und ist die ehrlichste Information, die so eine Schnittstelle Ihnen geben kann.
Das Problem ist nicht das Limit. Das Problem ist, dass die meisten No-Code-Workflows so gebaut sind, als gäbe es keins.
Warum No-Code-Tools das Problem verstecken
In einer richtigen Programmiersprache merken Sie schnell, dass eine API zickt. Sie bekommen einen Fehler, der Code bricht ab, Sie müssen sich darum kümmern. No-Code-Tools nehmen Ihnen genau diese Reibung ab, und das ist Segen und Fluch zugleich.
Wenn Sie in Make ein Modul ziehen, das 5000 Datensätze durchläuft und für jeden einen API-Call macht, sieht das im Editor harmlos aus. Eine Schleife, ein Modul, fertig. Was Sie nicht sehen: Diese 5000 Calls feuern so schnell hintereinander, wie das Tool sie verarbeiten kann. Bei einem Limit von zwei Anfragen pro Sekunde sind Sie nach einer Sekunde schon drüber.
Und jetzt kommt der Teil, der wirklich weh tut. Viele Workflows sind so konfiguriert, dass ein einzelner fehlgeschlagener Call den ganzen Durchlauf nicht stoppen soll, das will man ja auch nicht. Also wird der Fehler stillschweigend übersprungen. Aus Sicht des Tools ist alles in Ordnung. Aus Sicht Ihrer Daten fehlt jeder Datensatz, der ein 429 abbekommen hat. Grün auf dem Dashboard, Loch in der Datenbank.
Die drei Fehlerbilder, die wir immer wieder sehen
Das erste ist der stille Verlust, den wir oben beschrieben haben. Einzelne Datensätze verschwinden, niemand merkt es sofort, und wenn doch, ist die Ursache schwer zu finden, weil ja nichts kaputt aussieht.
Das zweite ist der halbe Sync. Der Workflow läuft bis zur Hälfte sauber, dann kippt die API ins Limit, und der Rest kommt nie an. Besonders gemein wird das, wenn Ihre Daten alphabetisch oder nach Datum sortiert sind, dann fehlt immer derselbe Teil, und es entsteht der Eindruck, ein ganzer Bereich Ihres Geschäfts sei nicht erfasst.
Das dritte ist die Eskalation durch Wiederholung. Ein Tool merkt, dass ein Call fehlschlägt, und versucht es sofort noch einmal. Und noch einmal. Jede Wiederholung ist ein weiterer Call gegen ein Limit, das Sie gerade ohnehin schon reißen. Statt sich zu beruhigen, treibt sich das System selbst tiefer ins Sperrfeuer. Bei manchen Anbietern verlängert sich die Sperre mit jedem zusätzlichen Versuch.
Wie man es richtig macht
Die gute Nachricht: Sie müssen kein Entwickler sein, um das in den Griff zu bekommen. Sie müssen nur aufhören, so zu tun, als wäre jede API unendlich belastbar.
Der erste Schritt ist drosseln statt feuern. Bauen Sie eine bewusste Pause zwischen die Calls. Wenn die API zwei Anfragen pro Sekunde erlaubt, dann schicken Sie nicht hundert auf einmal, sondern verteilen Sie sie. Ein paar Hundert Millisekunden Wartezeit zwischen den Aufrufen klingt nach Verschwendung, sind aber der Unterschied zwischen einem Sync, der durchläuft, und einem, der zur Hälfte verhungert.
Der zweite Schritt ist auf die Antwort hören. Wenn die API ein 429 zurückschickt und im "Retry-After"-Header steht, dass Sie zehn Sekunden warten sollen, dann warten Sie zehn Sekunden. Genau das. Nicht raten, nicht sofort neu feuern, sondern die Zahl nehmen, die der Anbieter Ihnen nennt. Diese eine Gewohnheit löst einen großen Teil aller Probleme mit Rate Limits.
Der dritte Schritt ist intelligentes Wiederholen. Wenn Sie es erneut versuchen, dann mit wachsendem Abstand. Erst nach einer Sekunde, dann nach zwei, dann nach vier. In der Softwareentwicklung heißt das exponentielles Backoff, und es ist nichts anderes als die Einsicht, dass ein überlastetes System mehr Ruhe braucht, nicht weniger.
Der vierte Schritt ist weniger fragen. Oft ist die sauberste Lösung, die Zahl der Calls von vornherein zu senken. Brauchen Sie wirklich für jeden einzelnen Kontakt einen eigenen Aufruf, oder kann die API hundert auf einmal entgegennehmen? Viele Schnittstellen bieten Batch-Endpunkte, mit denen Sie ein Vielfaches an Daten in einem einzigen Call bewegen. Das ist fast immer besser, als die Drosselung bis ins letzte zu perfektionieren.
Was die Tools konkret hergeben
In Make können Sie pro Szenario einstellen, wie viele Operationen gleichzeitig laufen, und mit dem Sleep-Modul gezielt Pausen einbauen. Der Iterator in Kombination mit einer kleinen Wartezeit ist oft schon die halbe Miete. Wichtig ist, dass Sie die Fehlerbehandlung nicht auf "ignorieren" stehen lassen, sondern 429 als das behandeln, was es ist: ein "gleich nochmal", kein "vergiss es".
In n8n haben Sie mehr Kontrolle, weil Sie im HTTP-Request-Node Wiederholungen mit Wartezeit direkt konfigurieren können. Viele der fertigen Integrationsknoten bringen ein eigenes Handling für Rate Limits mit, der generische HTTP-Knoten dagegen nicht, und genau dort entstehen die meisten Probleme. Wer selbst hostet, kann zusätzlich die Parallelität global begrenzen.
In Zapier ist die Kontrolle am geringsten, dafür übernimmt die Plattform einen Teil der Arbeit im Hintergrund. Bei großen Datenmengen stoßen Sie hier aber schnell an Grenzen, und die einzige verlässliche Stellschraube ist oft, die Last über die Zeit zu strecken, statt alles in einen Lauf zu pressen.
Woran Sie erkennen, ob es Sie schon betrifft
Sie müssen dafür nicht den Code lesen. Es reicht, an den richtigen Stellen nachzusehen. Vergleichen Sie für einen Lauf die Zahl der Datensätze am Eingang mit der Zahl am Ausgang. Wenn vorne 5000 reingehen und hinten 4700 ankommen, ohne dass eine Regel die fehlenden 300 erklärt, haben Sie eine heiße Spur.
Werfen Sie außerdem einen Blick in das Ausführungsprotokoll Ihrer Plattform und filtern Sie nach dem Statuscode 429 oder nach Meldungen mit "rate limit" und "too many requests". In Make und n8n stehen diese Antworten im Verlauf, auch wenn der Workflow am Ende grün gemeldet hat. Und achten Sie auf ein verräterisches Muster: Treten die Fehler immer am Ende langer Läufe auf oder genau dann, wenn mehrere Automatisierungen gleichzeitig auf dieselbe API zugreifen? Dann ist nicht Ihre Logik schuld, sondern schlicht die Menge.
Der Punkt, an dem es sich entscheidet
Rate Limits sind kein exotisches Randthema. Sie sind der Moment, in dem sich entscheidet, ob eine Automatisierung mit Ihrem Geschäft mitwächst oder bei der ersten ernsthaften Datenmenge zusammenbricht. Solange Sie zehn Datensätze pro Nacht abgleichen, merken Sie nichts. Bei zehntausend trennt sich die Spreu vom Weizen.
Unser Rat ist unspektakulär: Bauen Sie jeden Workflow, der mehr als eine Handvoll Calls macht, von Anfang an so, als würde die API irgendwann Nein sagen. Denn das wird sie. Die Frage ist nur, ob Ihr System darauf vorbereitet ist oder ob Sie es an einem Montagmorgen herausfinden, wenn 600 Kontakte fehlen und niemand weiß, warum.