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

Описание и применение

В n8n‑workflow, который обрабатывал только первую страницу paginated API, пропускались десятки заказов, хотя процесс завершался успешно. Добавлены проверки наличия следующей страницы, сохранение состояния после каждой страницы и дедупликация по бизнес‑ключу, что устраняет скрытые ошибки.

Задача

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

Результат

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

Рабочий процесс

• 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.

Доказательства

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

Источник

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."

Источник

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

Источник