Your n8n Workflow Only Processed the First Page: Pagination Bugs That Look Like Success

Description and use

An n8n workflow that processed only the first page of a paginated API missed dozens of orders while reporting success. Implementing page‑existence checks, stateful pagination, and deduplication on business keys resolved the silent data loss.

Problem

An n8n workflow that fetched only the first page of a paginated API missed dozens of orders, causing incomplete reports without any error signals.

Outcome

The updated workflow reliably fetches all pages, resumes correctly after failures, and deduplicates records, preventing silent data loss.

Workflow

• 1. Fetch first page of orders from API.
• 2. Write orders to spreadsheet.
• 3. Mark run as successful if HTTP response is received.
• 4. (Issue) No further pages fetched.
• 5. (Fix) Add loop to fetch pages until next cursor is empty or page size < limit.
• 6. Store cursor/offset after each page to enable resumption.
• 7. Deduplicate on order ID before writing.
• 8. Log counts of pages fetched, rows received, rows written, and duplicates skipped.

Evidence

The API returned 100 orders per page, and the workflow fetched exactly one page.

Source

My rule now: a fetch loop ends only on an explicit signal — an empty next cursor, or a page smaller than the limit — never on "we got one good response."

Source

Third, dedupe on the business key, not the row position.

Source