Ihre Automatisierung sieht nur die ersten 100 Datensätze, und niemand merkt es

Ein Workflow lief sechs Monate sauber durch und übersah trotzdem die Hälfte aller Kunden

Bei einem Kunden hat ein Make-Szenario jede Nacht die Kontakte aus dem CRM in das Newsletter-Tool synchronisiert. Sechs Monate lang grün, keine Fehlermeldung, kein Alarm. Dann fiel jemandem im Marketing auf, dass eine langjährige Kundin seit Monaten keine Mail mehr bekommen hatte. Wir haben nachgesehen. Das Szenario hatte nie mehr als 100 Kontakte pro Lauf verarbeitet. Im CRM standen längst über 600.

Niemand hatte etwas falsch gebaut. Der Workflow tat genau das, was im Editor stand. Er fragte die API nach Kontakten, bekam eine Liste zurück, arbeitete sie ab. Das Problem steckte in der Liste selbst: Die API liefert pro Anfrage nur die ersten 100 Einträge. Den Rest muss man aktiv nachfordern, Seite für Seite. Genau diesen Teil hatte niemand gebaut, weil beim Testen mit einer Handvoll Kontakten alles funktioniert hat.

Das ist die Pagination-Falle. Sie gehört zu den häufigsten stillen Fehlern, die uns in bestehenden Automatisierungen begegnen, und sie meldet sich nie von selbst.

Warum fast jede API Ihre Daten in Portionen ausgibt

Eine Schnittstelle, die auf eine einzige Anfrage zehntausend Datensätze auf einmal zurückgibt, würde sich selbst und die Leitung überlasten. Also liefern fast alle APIs die Daten in Seiten aus. Sie geben Ihnen einen Block, meist 25, 50 oder 100 Einträge, und einen Hinweis, wie Sie die nächste Seite abrufen. Mal ist das eine Seitennummer, mal ein Offset, mal ein sogenannter Cursor, also ein Zeiger auf den nächsten Block.

Entscheidend ist: Wenn Sie nur die erste Antwort nehmen und sich nicht um die Folgeseiten kümmern, bekommen Sie genau eine Portion. Alles dahinter existiert für Ihren Workflow nicht. Die API hat nicht gelogen, sie hat genau das geliefert, wonach gefragt wurde. Gefragt wurde nur nach der ersten Seite.

Warum der Fehler im Test nie auffällt

Das Tückische ist das Timing. Beim Bauen testet man mit wenig Daten, zehn Kontakte, fünf Bestellungen, drei Tickets. Alles passt bequem auf die erste Seite, also läuft alles korrekt. Der Workflow geht live, und monatelang bleibt die Datenmenge unter der Grenze. Niemand sieht ein Problem, weil es keins gibt.

Der Fehler entsteht nicht beim Bauen, sondern beim Wachsen. Irgendwann überschreitet die Datenmenge die Seitengröße, und ab da wird stillschweigend abgeschnitten. Kein roter Lauf, keine Benachrichtigung. Der Workflow verarbeitet weiter brav seine erste Seite und meldet jeden Lauf als Erfolg. Genau deshalb laufen diese Fehler oft über Monate, bis sie jemandem zufällig auffallen, so wie bei der Kundin, die keinen Newsletter mehr bekam.

Woran Sie erkennen, dass es Sie betrifft

Es gibt ein paar Anzeichen, die uns hellhörig machen. Wenn ein Workflow Lauf für Lauf exakt dieselbe runde Zahl verarbeitet, etwa immer genau 100, ist das fast nie Zufall, sondern die Seitengröße. Wenn die Zahlen zwischen Quellsystem und Zielsystem auseinanderlaufen, im CRM 600 Kontakte, im Newsletter 100, ist das ein klares Signal. Und wenn Mitarbeiter berichten, dass "manche Datensätze einfach fehlen", ohne ein erkennbares Muster, lohnt sich der Blick auf die Pagination, bevor man irgendwo anders sucht.

Wie wir es richtig bauen

Die Lösung ist kein Hexenwerk, sie muss nur bewusst gebaut werden. Statt einer einzelnen Anfrage braucht es eine Schleife: erste Seite holen, verarbeiten, nach der nächsten fragen, und das wiederholen, bis keine weitere Seite mehr kommt.

In n8n erledigt das oft die Einstellung "Return All" am jeweiligen Node, die die Folgeseiten automatisch durchläuft. Wo es die nicht gibt, baut man die Schleife mit einem HTTP-Node und dessen Pagination-Option selbst. In Make nimmt man einen Iterator oder einen Repeater und erhöht Seite oder Offset, bis die Antwort leer zurückkommt. Bei Zapier wird es unangenehm, weil die Standard-Trigger meist nur die neuesten Einträge liefern und echte Schleifen kaum vorgesehen sind. Das ist einer der Punkte, an denen Zapier bei größeren Datenmengen an seine Grenze stößt.

Wichtig ist die Abbruchbedingung. Eine Schleife, die nicht sauber erkennt, wann Schluss ist, läuft entweder endlos oder hört zu früh auf. Die verlässliche Regel: weitermachen, solange die API eine volle Seite zurückgibt, und stoppen, sobald eine Seite weniger Einträge als die Seitengröße enthält oder ganz leer ist.

Die eine Prüfung, die das Problem sofort sichtbar macht

Am Ende empfehlen wir immer denselben einfachen Check, und der kostet fünf Minuten. Lassen Sie den Workflow nach jedem Lauf zwei Zahlen vergleichen: Wie viele Datensätze hat das Quellsystem, und wie viele hat der Workflow verarbeitet? Stimmen sie nicht überein, geht eine Warnung raus.

Dieser Abgleich fängt nicht nur Pagination-Fehler, sondern jede Art von stillem Datenverlust. Er verwandelt einen Fehler, der sonst monatelang unsichtbar bliebe, in eine Meldung am selben Tag. Für uns gehört dieser Vergleich inzwischen zum Standard in jedem Workflow, der Datensätze in größeren Mengen verarbeitet.

Wenn Sie nicht sicher sind, ob Ihre Automatisierungen wirklich alle Datensätze sehen oder nur die jeweils erste Seite, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir gehen Ihre laufenden Workflows gemeinsam durch und prüfen genau die Stellen, an denen unbemerkt Daten verloren gehen.