Je n8n-request is groen. Heb je ook de laatste pagina opgehaald?

Een API geeft honderd records terug en de HTTP Request-node in n8n wordt groen. Dat vertelt nog niet of je honderd of duizend records had moeten krijgen. Veel APIs verdelen resultaten over pagina’s. Wie alleen de eerste response verwerkt, bouwt een workflow die technisch slaagt en inhoudelijk gegevens mist. Dat valt vaak pas op wanneer een collega een bekend record niet kan terugvinden.

De n8n-documentatie beschrijft ingebouwde paginering met een volgende URL of een parameter die per request wordt bijgewerkt. Welke methode past, hangt af van de API. Begin daarom bij het contract van het specifieke endpoint: de vorm van de response, toegestane paginagrootte en de beschreven eindconditie. Kopieer geen pagineringsinstelling uit een andere integratie zonder die verschillen te controleren.

Maak eerst één response begrijpelijk

Gebruik een toegestane leesaanroep of een bewaarde testresponse. Zoek de lijst met records, een stabiele record-ID en het veld of de header voor de volgende pagina. Leg ook vast welke filters en sortering actief zijn. Een totaal voor alle records is niet vergelijkbaar met een resultaat waarin alleen actieve bedrijven worden opgevraagd. Noteer wat het eventuele total-veld werkelijk telt.

Controleer of de API een momentopname of stabiele cursor ondersteunt. Wanneer records tijdens het ophalen veranderen, kan een verschuivende sortering gaten of overlap veroorzaken. Een net aantal unieke IDs bewijst dan nog niet dat de export op één gezamenlijk tijdstip compleet was. Benoem die beperking in plaats van het totaal als universele waarheid te presenteren.

Werkvoorbeeld: drie pagina’s, één controlemoment

FICTIEVE API
De testset bevat 230 records. Pagina 1 geeft 100 records en next=/records?cursor=B. Pagina 2 geeft 100 records en next=/records?cursor=C. Pagina 3 geeft 30 records en next=null. De fictieve documentatie zegt dat next=null het einde markeert.

CONTROLE
Ontvangen: 230 records. Unieke IDs: 230. Gevolgde pagina’s: 3. Eindconditie: next=null. Binnen deze vaste testset zijn alle 230 verwachte IDs aanwezig. Er is nog niets naar het CRM geschreven.

De laatste dertig records zijn hier niet zelfstandig het bewijs van voltooiing. De gedocumenteerde eindconditie is dat de volgende cursor ontbreekt. Een andere API kan juist minder dan honderd resultaten geven terwijl er nog een volgende pagina bestaat. Koppel je stopregel dus aan het contract, niet aan een aantrekkelijk ogende vuistregel.

Configureer en controleer apart

1. Open de HTTP Request-node en voeg Pagination toe. Gebruik Response Contains Next URL alleen wanneer de API daadwerkelijk een volgende URL teruggeeft.
2. Wijs het juiste veld aan. Een veld next op het hoogste niveau is niet hetzelfde als links.next.url. Controleer de echte response voordat je een expression invult.
3. Gebruik Update a Parameter in Each Request wanneer de API een paginanummer of andere bijgewerkte parameter verwacht. De ingebouwde $pageCount begint bij nul; tel alleen één op als het endpoint bij pagina één begint.
4. Controleer dat filters, sortering en noodzakelijke parameters bij vervolgaanroepen behouden blijven. Een next-link mag niet ongemerkt een ander datasetbereik ophalen.
5. Verzamel de records in een testuitkomst en vergelijk ontvangen aantallen, unieke IDs, het aantal pagina’s en de eindconditie voordat vervolgacties worden vrijgegeven.

Vier fouten die je test moet vangen

Laat de test ook misgaan. Gebruik een response die steeds dezelfde cursor teruggeeft: de uitvoering moet stoppen met een zichtbare fout in plaats van eindeloos door te lopen. Laat een vervolgrespons een autorisatiefout of rate limit bevatten: die mag niet als een lege laatste pagina gelden. Laat twee pagina’s dezelfde ID bevatten: tel ontvangen en uniek afzonderlijk. Laat tot slot het next-veld onverwacht verdwijnen: beoordeel of dit volgens het API-contract werkelijk einde betekent.

Een maximale paginagrens is een nuttige noodrem, maar geen bewijs dat alle data binnen is. Als je grens wordt bereikt terwijl een volgende pagina bestaat, is het resultaat gedeeltelijk. Geef dat als status door en houd de laatste volledig verwerkte checkpoint intact. Automatiseer niet dat een onvolledige lijst meteen de bestaande CRM-lijst vervangt of ontbrekende records verwijdert.

Wat je aan het einde wilt kunnen aanwijzen

Bewaar een klein uitvoerverslag: gebruikte filters, start- en eindtijd, pagineringenvelop zonder geheimen, ontvangen aantal, uniek aantal, waargenomen eindconditie en eventuele afwijkingen. Bewaar geen volledige persoonsgegevens alleen om te bewijzen dat je hebt gepagineerd. Gebruik een beperkt testbestand met fictieve IDs voor regressietests.

Deze controle gaat over volledigheid van het ophalen. Dubbelen voorkomen bij het later verzenden van mails of schrijven van orders is een andere stap. Laat de workflow pas doorgaan wanneer je precies kunt uitleggen waarom dit resultaat volledig is, of waarom het bewust als gedeeltelijk wordt aangeboden. Groen is prettig; een navolgbare eindconditie maakt het bruikbaar.