n8n returns only first API page? Audit the sync

How will we prove that the last record was fetched? That is the acceptance question when an n8n HTTP Request node reports a clean execution but imports only the first page of customer, order or contact records.

Abstract data cards continuing beyond an unfinished pagination route

For a service business in Dubai, the UK or Liverpool, an incomplete CRM sync can look perfectly respectable until a report misses prospects or a follow-up workflow quietly skips people. The request succeeded. The job did not necessarily finish.

Start with a population you can count

Do not begin by changing the node and rerunning a live sync. First establish a known test population from the provider: a controlled date range, account segment or other set where you can inspect the expected unique record IDs.

You do not need to publish production numbers or copy customer data into n8n. A redacted list of identifiers is enough. What matters is that there is a sensible answer to two dull but important questions: how many distinct records should arrive, and which ID proves the final record arrived?

For example, an illustrative CRM sync may request contacts created during a defined test period. The first response contains a full-looking batch, n8n marks the node green, and downstream steps prepare onboarding messages. Yet the API response also indicates that another page exists. Without pagination, the automation has merely processed the front of the queue.

If the sync feeds a customer journey, this is worth sorting before the workflow starts sending anything. Our notes on client onboarding automation that stays personal cover the handover point where correct data needs to become a useful next action, rather than an automated cold shoulder.

Read the API contract, not the first response alone

An API decides how pagination works. Some providers return a next-page URL. Others expect n8n to increment a page, offset or cursor parameter. Cursor-based APIs may return an opaque token which must be passed back exactly as supplied. A page number is not interchangeable with a cursor simply because both eventually fetch more records.

The n8n HTTP Request pagination guidance documents pagination using either a next URL or a changing parameter, and points out that the provider’s page limits and response structure need checking. That last bit is where plenty of otherwise tidy workflows go astray.

Inspect the actual response body and headers for the provider’s contract. Look for details such as:

  • the maximum records allowed per page
  • the location of the next URL, cursor or page indicator
  • the parameter name n8n must change on each request
  • the field containing the returned record array
  • the precise condition which means there are no more pages

It is tempting to assume that requesting a larger limit means the entire dataset will arrive. It usually means only that the API will return a larger first page, up to its own cap.

Configure the route and the stopping condition together

n8n’s HTTP Request node can paginate through a next URL or by changing a parameter. The right setup depends on the provider, so copy the contract rather than improvising a loop from memory.

Set a safety limit as well. This is not an alternative to a proper stopping rule. It is a guard against an unexpectedly repeated next URL, a cursor that does not advance, or a parameter expression that keeps requesting page one. A high enough safety limit should accommodate the known test population without making an accidental loop run all afternoon.

For wider work involving CRM, forms, inboxes and operational handovers, business automation delivery support is useful when the problem is bigger than one node and needs a scoped route through the system.

Do not confuse a later page with a duplicate page

Check the record IDs from page one and page two. If they are identical, the pagination rule is not advancing. If page two contains different IDs but the workflow stops there despite more records being available, the stopping condition is likely wrong. Both can produce a reassuring green execution with an incomplete result.

One boring detail worth checking is the response field path. Some APIs return records directly in an array, while others place them inside a nested data or results field alongside paging metadata. Point the node at the wrong field and the page logic can look configured while the workflow is reading the wrong part of the response.

Reconcile unique IDs before enabling writes

An n8n HTTP Request only returns the first page when pagination has not been configured correctly, the next-page value is not being read from the provider response, or the workflow stops before the provider signals completion. Prove completeness by comparing the unique IDs retrieved across all pages with a known test population, then confirm that an empty or final page ends the process cleanly before allowing downstream writes.

Use a small acceptance sequence:

  1. Run the request against the known test population.
  2. Collect unique IDs from every returned page.
  3. Compare them with the expected ID list from the provider.
  4. Confirm the final populated page is included.
  5. Confirm the following empty response, absent next URL or terminal cursor ends the workflow as intended.
  6. Only then allow create, update, email or task-writing nodes to run.

This is less glamorous than staring at a successful execution badge, but it protects reports and follow-up activity from gaps that may take weeks to notice. Validate completeness as well as request success.

Keep incomplete retrieval separate from recovery after writes

A first-page-only fault is a read-completeness problem. It should be fixed before writes begin. If a workflow has already written some records and then needs careful recovery, that is a different boundary involving partial completion and idempotency. See how to handle n8n 429 retries without replaying writes for that separate problem.

FAQ: is it pagination or an API filter?

How do I distinguish pagination from an API filter that excludes records?

Compare the returned IDs with a known provider-side test population, then inspect the request parameters. A pagination issue usually shows a complete-looking first batch and evidence that another page or cursor exists. A filter issue returns fewer records because the API query excludes them by date, status, ownership or another condition. Test the same filter directly in the provider before altering pagination.

Make the completion test part of the handover

Document the page limit, next-page rule, stopping condition and ID reconciliation check alongside the workflow. The next person should not have to infer why a cursor expression exists, especially after a provider changes its API response shape.

Share the API’s pagination documentation and a redacted sync example for review. A short look at the contract and execution data is usually more useful than guessing which node setting has taken the hump.