Many n8n users build manual pagination with Loop + HTTP Request + IF (check for more pages) + Merge.
Many n8n users build manual pagination with Loop + HTTP Request + IF (check for more pages) + Merge. The HTTP Request node has a built-in pagination feature that handles this automatically with far less overhead and no risk of infinite loops.
Real-world example: Fetching all repositories from the GitHub API, which returns 30 items per page with a Link header containing the next page URL.
HTTP Request node configuration:
| Setting | Value |
|---|---|
| Method | GET |
| URL | https://api.github.com/orgs/your-org/repos |
| Authentication | Predefined Credential (GitHub API) |
| Pagination | |
| Pagination Mode | Response Contains Next URL |
| Next URL | {{ $response.headers.link?.match(/<([^>]+)>;\s*rel="next"/)?.[1] }} |
| Max Pages | 50 |
| Options | |
| Batch Size | 1 |
For APIs using offset-based pagination:
| Setting | Value |
|---|---|
| Pagination Mode | Update a Parameter in Each Request |
| Parameter Name | offset |
| Parameter Type | Query |
| Initial Value | 0 |
| Next Value | {{ $response.body.offset + $response.body.limit }} |
| Stop Condition | {{ $response.body.results.length === 0 }} |
This eliminates the need for the Split In Batches loop pattern for simple pagination and reduces execution time because there is no inter-node overhead per page.
Related: Flatten Deeply Nested API Responses | Use Docker Compose with Health Checks for n8n and PostgreSQL
I build production n8n and Cloudflare automation for teams — the same engineering behind HarperFlow. Fixed-price, escrow-protected, US-based.