Ein Workflow zieht Kontakte aus einem CRM, verarbeitet sie sauber – und übersieht trotzdem die Hälfte. Keine Fehlermeldung, kein roter Node: Die Schnittstelle hat einfach nur die erste Seite geliefert, der Rest blieb unbemerkt liegen. Solche stillen Datenlücken gehören zu den tückischsten Fehlern in der Automatisierung, weil alles funktioniert zu haben scheint. Ich zeige, warum APIs ihre Antworten in Seiten aufteilen und wie Sie mit der Pagination-Funktion des HTTP-Request-Nodes in n8n zuverlässig an alle Datensätze kommen.
Warum eine API ihre Antwort in Seiten aufteilt
Eine Schnittstelle, die auf eine einzige Abfrage zehntausend Datensätze zurückschickt, wäre langsam, speicherhungrig und für beide Seiten riskant. Deshalb deckeln fast alle APIs die Menge pro Antwort und liefern den Rest häppchenweise – Seite für Seite. Stripe etwa gibt pro Aufruf standardmäßig 10 Objekte zurück und höchstens 100, wie die API-Dokumentation festhält. Fragen Sie 4.000 Zahlungen ab, bekommen Sie also mindestens 40 Seiten. Wer nur den ersten Aufruf macht, hält 100 Datensätze in der Hand – und hält sie fälschlich für alle.
Das Heimtückische daran: Der Workflow läuft grün durch. Er bekommt eine gültige Antwort, verarbeitet sie und meldet Erfolg. Dass 3.900 Datensätze fehlen, merkt niemand, bis eine Auswertung nicht aufgeht oder ein Kunde eine ausbleibende Mail reklamiert.
Die drei Muster: Seitenzahl, Offset und Cursor
Bevor Sie in n8n irgendetwas einstellen, müssen Sie wissen, wie die konkrete API paginiert. Das steht in ihrer Dokumentation und folgt fast immer einem von wenigen Mustern. Sie unterscheiden sich darin, wie Sie der Schnittstelle sagen „gib mir die nächste Seite“.
| Muster | Woran Sie es erkennen |
|---|---|
| Seitenzahl | Parameter wie page und per_page; Sie zählen die Seite hoch |
| Offset | Parameter wie offset und limit; Sie springen in Schritten der Seitengröße |
| Cursor | Ein Token wie starting_after oder next_cursor, das auf den letzten Datensatz zeigt |
| Nächster Link | Die Antwort enthält die fertige URL der nächsten Seite – im Body oder im Link-Header |
Seitenzahl und Offset kann n8n aus einem simplen Zähler ableiten. Beim Cursor und beim nächsten Link müssen Sie einen Wert aus der jeweils letzten Antwort weiterreichen – auch das geht, nur anders.
Pagination im HTTP-Request-Node aktivieren
n8n muss die Schleife nicht von Hand gebaut werden. Der HTTP Request-Node bringt Pagination eingebaut mit: Sie öffnen ihn, wählen Add Option und dann Pagination. Danach erscheint das Feld Pagination Mode mit zwei nutzbaren Verfahren, wie die offizielle Anleitung zeigt. Welches Sie brauchen, hängt am Muster aus der Tabelle oben.
Drei Variablen stehen dabei nur im HTTP-Node zur Verfügung: $pageCount zählt, wie viele Seiten der Node bereits geholt hat, $response ist die letzte Antwort (mit $response.body, $response.headers und $response.statusCode) und $request die zuletzt gesendete Anfrage.
Seitenzahl hochzählen mit $pageCount
Für das Muster mit Seitenzahl setzen Sie Pagination Mode auf Update a Parameter in Each Request, Type auf Query und tragen unter Name den Parameter ein, den die API erwartet – oft page. Beim Value schalten Sie den Ausdrucks-Modus ein und schreiben:
{{ $pageCount + 1 }}
$pageCount beginnt bei null. Die meisten APIs zählen ihre Seiten aber ab eins, deshalb das + 1: Im ersten Durchlauf fragt der Node Seite eins ab, im zweiten Seite zwei und so weiter. Die Seitengröße selbst geben Sie nicht hier, sondern oben in den normalen Query-Parametern des Nodes an – etwa per_page oder limit mit dem Wert 100. Bei einer Offset-API bleibt alles gleich, nur der Ausdruck ändert sich: Bei einer Seitengröße von 100 rechnen Sie {{ $pageCount * 100 }} und tragen ihn beim offset-Parameter ein.
Den nächsten Link aus der Antwort folgen
Cursor- und Link-APIs verraten die nächste Seite erst in ihrer Antwort. Dafür wählen Sie Pagination Mode → Response Contains Next URL und tragen unter Next URL einen Ausdruck ein, der die Adresse aus der letzten Antwort zieht. Liefert die API die nächste URL im Body – etwa in einem Feld next-page –, sieht das so aus:
{{ $response.body["next-page"] }}
Manche Schnittstellen legen den Verweis stattdessen in einen Link-Header. GitHub etwa antwortet mit einer Zeile wie <https://api.github.com/…?page=4>; rel="next", <…?page=515>; rel="last", dokumentiert in der REST-API-Referenz. Diesen Wert erreichen Sie über $response.headers, müssen die passende URL aber per Ausdruck aus dem Header herauslösen – das ist fummeliger als der saubere Fall im Body.
Wann n8n aufhören soll: die Abbruchbedingung
Damit die Schleife nicht endlos läuft, braucht der Node ein Stoppsignal. Das Feld Pagination Complete When kennt drei Optionen: Response Is Empty hört auf, sobald eine Seite leer zurückkommt – der Normalfall bei Seitenzahl und Offset. Receive Specific Status Code(s) stoppt bei bestimmten HTTP-Statuscodes. Und Other erlaubt eine eigene Bedingung als Ausdruck. Genau die brauchen Sie bei Cursor-APIs wie Stripe, die im Body ein Feld has_more mitschicken:
{{ $response.body.has_more === false }}
Pagination ist kein Nice-to-have, sondern eine Frage der Korrektheit: Ohne sie verarbeitet eine Automatisierung stillschweigend nur die erste Seite und meldet trotzdem Erfolg. Der HTTP-Request-Node in n8n holt alle Seiten selbst, wenn Sie ihm drei Dinge nennen – wie die nächste Seite adressiert wird, wann Schluss ist und wie viele Seiten höchstens erlaubt sind.
Dieses Maximum ist die dritte Angabe. Über Limit Pages Fetched blenden Sie das Feld Max Pages ein und setzen eine Obergrenze. Das ist Ihr Sicherheitsnetz: Falls die Abbruchbedingung wegen eines API-Sonderfalls nie greift, stoppt n8n trotzdem nach der festgelegten Zahl, statt Tausende Aufrufe abzufeuern. Beim Einrichten lohnt sich ein kleiner Wert wie 2, um die Konfiguration schnell zu testen, bevor Sie die Grenze hochsetzen.
Zwei Fallen: Arbeitsspeicher und Rate Limits
Die eingebaute Pagination ist bequem, hat aber eine Eigenheit, die man kennen muss: n8n sammelt alle Seiten im Arbeitsspeicher und reicht erst das komplette Ergebnis an den nächsten Node weiter. Bei 40 Seiten ist das egal, bei 40.000 Datensätzen kann es die Instanz an ihre Grenze bringen. Die Gegenmittel: serverseitig filtern, statt alles zu holen (viele APIs bieten Datums- oder Status-Filter als Query-Parameter), eine realistische Max Pages-Grenze setzen, und die Rohdaten früh auf die wirklich benötigten Felder eindampfen, bevor sie sich seitenweise stapeln. Wenn die Menge weiter wächst, ist ein Zielspeicher wie eine Tabelle oder Datenbank sinnvoller als das Weiterreichen im Speicher.
Die zweite Falle: Wer schnell hintereinander 40 Seiten anfragt, läuft leicht in das Rate Limit der Gegenseite. Genau dafür gibt es beim Pagination-Node das Feld Interval Between Requests (ms) – eine feste Pause zwischen den Seitenaufrufen. Wie Sie erkennen, welche Frequenz eine API erlaubt, und was bei einem 429 Too Many Requests zu tun ist, habe ich in Rate Limits: Wenn die API die Automatisierung bremst beschrieben.
Und noch ein Punkt, der in der Praxis zählt: Bricht ein Aufruf mitten in der Pagination ab – Seite 23 von 40 –, ist der Durchlauf unvollständig, ohne dass es auffallen muss. Ein sauberes Fehler- und Monitoring-Konzept gehört deshalb zu jeder Automatisierung, die größere Datenmengen über Schnittstellen zieht.
Fazit
Pagination ist keine Kür, sondern der Unterschied zwischen „hat die ersten 100 verarbeitet“ und „hat alle verarbeitet“. Der HTTP-Request-Node nimmt Ihnen die Schleife ab, sobald Sie das Muster der API kennen, den richtigen Modus wählen und eine Abbruchbedingung samt Seitenobergrenze setzen. Der Aufwand ist klein, der stille Datenverlust ohne sie groß.
Wenn Sie unsicher sind, ob Ihre Automatisierung wirklich alle Datensätze erfasst – oder ganz grundsätzlich einen Prozess sauber an eine Schnittstelle anbinden wollen –, schauen wir das gemeinsam an. In einem kostenlosen Prozess-Check klären wir, wo bei Ihnen Daten verloren gehen und wie eine belastbare Anbindung aussieht. Tiefer in die Möglichkeiten von n8n geht meine n8n-Beratung.