Master API Pagination in n8n for REST & GraphQL

Integrating with third-party APIs is often the backbone of automation in modern web apps, SaaS products, and digital agencies. But if you’ve ever tried fetching more than a handful of records from a REST or GraphQL API, you’ve probably hit the “pagination wall.” Maybe your workflow only imports the first page. Maybe it loops endlessly. Maybe (worst of all) it silently skips data when the structure isn’t perfectly anticipated.

If you’re using n8n for automation, you know it brings flexibility and power—but handling paginated results isn’t something to leave to chance. Doing it incorrectly doesn’t just mean slower or incomplete automations; it can mean lost revenue, inaccurate analytics, and broken downstream processes. Getting pagination right is crucial for building workflows that are robust and reliable, even as APIs evolve.

Let’s walk through what API pagination really means, how to implement it correctly in n8n for both REST and GraphQL endpoints, what common gotchas to watch out for, and where there are trade-offs or better approaches.

What is API Pagination and Why It Matters

APIs often limit the number of records they return in one response, primarily to avoid performance bottlenecks and to give clients control over how much data to process at once. Pagination is the practice of splitting large sets of data into “pages,” with each API response returning just one chunk. The client (your workflow) must make repeated requests to fetch the rest.

There are several common pagination strategies:

• Offset-based: Uses parameters like limit and offset or page and pageSize to get slices of data.
• Cursor-based: Returns a cursor (token) for the next page, which you must provide in the next request.
• Link-based (or “next” URL): The API includes a full URL or path for the next page in the response.
• GraphQL-specific: Typically involves returning a pageInfo object with endCursor and hasNextPage flags.

Why does this matter? Without handling pagination, n8n will only fetch the first batch of records. If your use case involves syncing users, scraping e-commerce products, or auditing data, this means you’ll miss most of your target data. Proper pagination logic is not a nice-to-have; it’s fundamental to complete, trustworthy automation.

How to Implement API Pagination in n8n Step-by-Step

Let’s break this down for both RESTful APIs and GraphQL endpoints—with practical, battle-tested techniques for each.

REST API Pagination

1. Read the API Documentation Carefully

Before you do anything, check how the target API implements pagination:

• Are there limit and offset or page parameters?
• Does the response include a “next” link or a total count?
• Is a cursor or token required?

Example for offset-based pagination:

GET /api/items?limit=100&offset=0
{
  "items": [...],
  "total": 456,
  "limit": 100,
  "offset": 0
}

2. Configure n8n’s HTTP Request Node

n8n’s HTTP Request node supports pagination out of the box for many styles. In the node’s settings, look for the Pagination section. You’ll typically choose:

• Offset-based: Set the pagination type, enter the parameter names for limit and offset, and use expressions to update offset (e.g., {{ $page * 100 }}).
• Link-based: If the API returns a next URL in the response, specify the JSON path to that property, and n8n will automatically follow it.

Example configuration for offset-based:

• Pagination Type: Offset
• Limit Parameter: limit
• Limit Value: 100
• Offset Parameter: offset
• Offset Value: {{ $page * 100 }}

3. Avoid Manual Loop Logic When Possible

When n8n’s built-in pagination can follow all pages via built-in settings, use it—this minimizes errors and simplifies maintenance.

4. Test with Real Data

Always start by fetching a small limit (maybe 5 or 10 items) and observe how the workflow iterates. Check the output for completeness.

GraphQL API Pagination

Most GraphQL endpoints use cursor-based pagination. The pattern typically looks like this:

Request:

query {
  items(first: 100, after: "ENDCURSOR") {
    nodes { id name }
    pageInfo {
      endCursor
      hasNextPage
    }
  }
}

1. Initial GraphQL Request

Start with after: null or omit the after argument to fetch the first page.

2. Check hasNextPage and Iterate

After processing the results, look at pageInfo.hasNextPage. If it’s true, make another request, using endCursor as the new after value.

3. Implement a Loop in n8n

While n8n’s HTTP Request node doesn’t offer native GraphQL pagination support yet, you can use [Set], [IF], and [HTTP Request] nodes in a loop. Pseudocode workflow:

• Start with no cursor.
• Send request, parse response for endCursor and hasNextPage.
• IF: hasNextPage is true, update cursor and loop again.
• STOP when hasNextPage is false.

Example n8n Workflow Outline

1. [Set] – Set after to null.
2. [HTTP Request] – Send initial GraphQL query.
3. [Set] – Extract endCursor and hasNextPage.
4. [IF] – If hasNextPage, go to step 2 with updated after.
5. Merge all results.

Common Mistakes and How to Avoid Them

Handling pagination is simple in theory, but there are practical pitfalls that can break production automations:

1. Misreading the Pagination Model

Some APIs use offset, others page, others a next cursor. Always check the API docs—and inspect a real response—to confirm.

How to avoid: Compare documentation with sample responses. In n8n, map parameter names exactly. A mismatch can result in fetching the same page repeatedly or missing pages.

2. Forgetting to Stop the Loop

If you don’t check for the end condition (hasNextPage == false, next URL is null, or offset exceeds total records), you risk creating infinite loops or excessive API calls.

How to avoid: Use n8n’s built-in loop termination. For GraphQL, always check hasNextPage or for an empty endCursor.

3. Hardcoding Limits or Cursors

If you write offsets or cursor values by hand instead of using expressions, your workflow only ever handles one page.

How to avoid: Use n8n’s expressions (like {{ $page * 100 }} for offsets or dynamic variables for cursors).

4. Not Handling Mid-Workflow Changes

If data changes during a long data fetch (say, bulk deleting or adding records between calls), some APIs might return duplicate or missed items, especially with offset-based pagination.

How to avoid: Where possible, prefer cursor-based pagination for large data sets—it tends to be more reliable against shifting data. For offset pagination, minimize the time between fetches.

5. Not Merging All Pages’ Data

New users of n8n sometimes only process items from the last page, overwriting previous data.

How to avoid: Accumulate items from all pages before further processing.

Trade-Offs and When Not to Use This Approach

While n8n’s pagination handling covers most practical needs, a few scenarios call for different strategies:

1. Very Large Data Sets

For hundreds of thousands or millions of records, pulling all data in a single batch workflow can overload n8n, the server, or the API itself.

Alternative: Instead of fetching everything in one run, consider incremental updates: pull only new or recently changed records, if the API supports it, or paginate over smaller windows using scheduled runs.

2. APIs Without Clear Pagination

Some APIs don’t provide total counts or expose clear next/hasNext values. Here, you may need to fall back to manual loop constructs, or even script pre-processing outside n8n.

3. Sensitive Rate Limits

Bulk fetching with pagination can easily exhaust API rate limits. If you run jobs on large datasets, be sure to insert delays, track limits, and handle 429 (Too Many Requests) responses gracefully.

4. Changing Data or Inconsistent Snapshots

If the underlying data can change rapidly during a multi-page fetch (like deleting or adding many rows mid-job), offset-based pagination may lead to duplicate or skipped records. Cursor-based approaches are generally more robust, but even then, performing such queries in a single consistent snapshot is safer if the API allows.

Conclusion and Next Steps

API pagination isn’t just a checkbox in your workflow checklist—it’s the difference between reliable, scalable automations and brittle, error-prone scripts. With n8n, handling REST and GraphQL paginated APIs can be straightforward if you leverage the HTTP Request node’s settings, pay attention to the API’s specific model, and rigorously check loop conditions.

Offset, cursor, link, or pageInfo-based—each model has its quirks, and n8n adapts to cover most of them with the right configuration. The result: data integrations that pull complete, up-to-date results every time, ready to power whatever automations, reports, or notifications you need.

Start small. Test carefully. And don’t hesitate to dig into response payloads and documentation—the difference is in the details when it comes to bulletproof automation.