n8n HTTP Request Node Pagination: Complete Guide with Real API Examples

Pagination is one of the biggest sticking points for n8n users working with APIs. You make a request, get 20 results back, and realize there are thousands more you can’t reach. Or you get all the data but it comes back in a nested structure that looks impossible to work with. Either way, you end up deep in documentation or writing complex code nodes that didn’t need to be that complicated.

This guide covers everything you need to know: how pagination works, how to configure it inside the n8n HTTP Request node, and how to clean up the response data into something usable — all with real API examples using the PokeAPI and the Rick and Morty API.

What Is API Pagination and Why Does It Exist?

Pagination is how APIs split large datasets into smaller chunks delivered across multiple requests. Instead of returning 50,000 records in a single response (which would be slow, server-intensive, and prone to timeouts), an API returns a manageable page of results and provides a way to fetch the next page.

You see this every day on the web. An Amazon search returns 50 products per page. At the bottom you see page numbers: 1, 2, 3 … 20. A counter shows “Results 1–50 of 10,000+.” APIs work the same way — each response contains a batch of records plus instructions for how to get the next batch.

In n8n, the HTTP Request node has built-in pagination support that handles all of this automatically. Once configured correctly, it keeps making requests and collecting results until there are no more pages — no loops, no custom code, no manual orchestration required.

Example 1: Fetching All Pokémon with the PokeAPI

The PokeAPI is a free, public API with no authentication required — a great starting point for learning pagination. A basic GET request to https://pokeapi.co/api/v2/pokemon returns a JSON object containing a count (total number of Pokémon), a next URL (the next page), a previous URL (the previous page), and a results array with the current page of entries.

By default the API returns 20 results per page. You can add query parameters to change this: ?limit=60 returns 60 results at a time, and ?offset=60 skips the first 60 records and starts from result 61. These parameters can be combined and also work alongside the automatic pagination settings in n8n.

Configuring Pagination in the HTTP Request Node

To enable pagination in n8n’s HTTP Request node, scroll down to the Pagination section in the node settings. The key settings to configure are:

Pagination Mode — Set this to Response Contains Next URL. This tells n8n that the API response itself will include a URL for the next page of results.

Next URL — This is an expression that points to where the next URL lives in the response body. For the PokeAPI, set this to {{ $response.body.next }}. Each time n8n fetches a page, it reads this field, follows the URL, and repeats until the field is empty.

Pagination Complete When — Set this to Other and write the expression: {{ $response.body.next === null }}. When the PokeAPI reaches the last page, the next field becomes null instead of a URL. This expression tells n8n to stop at that point. Make sure these fields are set to Expression mode rather than Fixed — a common mistake that causes pagination to not work.

Limit Pages Fetched — Optional. Leave blank to fetch all pages, or set a number to cap how many requests are made.

Interval Between Requests — Optional. Set a delay in milliseconds between each page request to avoid hitting API rate limits. For production workflows, a small delay (500–1000ms) is recommended even if the API doesn’t strictly require it.

How Pagination Knows When to Stop

The two most important things to get right with any paginated API are: how to get from one page to the next, and how to know when you’ve reached the last page. Get those two right and you’re 90% of the way there.

For the PokeAPI, when you’re on the first page, the response has next pointing to the second page URL and previous as null. On the last page, it flips: previous contains a URL and next is null. The pagination complete expression watches for that null and stops the loop.

After running with pagination enabled, a PokeAPI workflow will execute 68 requests (1,350 Pokémon ÷ 20 per page = 67.5, rounded up) and return all 1,350 entries as individual items. The last batch will contain only 10 entries since 1,350 isn’t evenly divisible by 20 — that’s expected behavior.

Cleaning Up the Response: Edit Fields + Split Out

After running the paginated HTTP Request node, the raw output isn’t immediately usable. Each item contains the full response structure: a count, next, previous, and a results array. You don’t need count, next, or previous at this stage — you just need the results.

The fix is two nodes added after the HTTP Request node, and neither requires any code:

Edit Fields — Add an Edit Fields node and map only the results field from the response. This strips out everything else and gives you an array of Pokémon objects per page.

Split Out — Add a Split Out node immediately after, pointed at the results field. This takes the array and expands it so that each Pokémon becomes its own row. Your output goes from 68 arrays of 20 objects each to 1,350 individual rows with name and url columns — exactly what you’d want to pipe into a spreadsheet, database, or downstream node.

This Edit Fields → Split Out pattern works for the vast majority of paginated APIs and is far simpler than writing a code node to manually flatten arrays.

Example 2: Rick and Morty API — A Different Pagination Structure

The Rick and Morty API demonstrates an important point: every API structures its pagination response differently, and you need to read the response to figure out how to configure n8n. A GET request to https://rickandmortyapi.com/api/character returns a response with an info object (containing count, pages, next, and prev) and a results array of character objects — each with fields like id, name, status, species, gender, origin, location, image, and episode appearances.

The key difference from the PokeAPI is where the next URL lives. Here it’s nested inside the info object, so the Next URL expression becomes {{ $response.body.info.next }} and the completion expression becomes {{ $response.body.info.next === null }}. The logic is identical — just the path changes.

Limiting Pages and Handling Rate Limits

For the Rick and Morty API, a full paginated run returns 42 pages of results. If you only need a sample — or if you want to test your workflow before running it at full scale — use the Limit Pages Fetched setting to cap the number of requests.

Setting Limit Pages Fetched to 10 and Interval Between Requests to 1000 (milliseconds) will fetch the first 10 pages with a one-second delay between each request. The workflow takes about 10 seconds to complete and returns 10 pages of results rather than all 42.

Even for APIs that don’t explicitly enforce rate limits, adding a small interval is good practice. In production, unexpected spikes or retries can push you over undocumented limits, and a 500–1000ms delay between requests adds almost no real-world latency while significantly reducing that risk.

Cleaning Rick and Morty Results

The same two-node pattern applies here, with one small addition since the Rick and Morty characters have many more fields than the PokeAPI results.

First, use Edit Fields to extract only the results array from each response (dropping info and everything else). Then use Split Out on the results field to expand each character into its own row. At this point you have all the character fields available — name, status, species, gender, origin, image, and more — but all as separate columns.

If you only need a subset of those columns, add a second Edit Fields node at the end and pick exactly the fields you want. For example, mapping just name, status, and gender gives you a clean three-column table of every Rick and Morty character — ready for a spreadsheet, database insert, or any further processing.

Key Takeaways for Paginating Any API in n8n

Regardless of which API you’re working with, the process is the same: test one page first to see what the response structure looks like, find where the next-page URL or token lives in that response, write that path as an expression in the Next URL field, and determine what signals the last page (null, empty string, missing field, or a specific status code).

From there, the built-in n8n HTTP Request node handles the looping automatically. Use Limit Pages Fetched to cap results during testing, add Interval Between Requests for rate limit safety in production, and clean up the output with Edit Fields + Split Out instead of reaching for a code node. This pattern handles the vast majority of REST API pagination scenarios without writing a single line of JavaScript.