Make.com API Pagination Guide

A scenario that pulls records from an API and works perfectly in testing has a way of quietly breaking the moment real data volume shows up. Test with ten contacts and everything looks fine. Point it at a CRM with four thousand and it silently returns only the first fifty, because almost every API paginates its responses and the scenario was never built to ask for page two. This post covers how pagination actually works, the three patterns you will run into most often, and how to build a loop in Make that fetches everything rather than just the first page.

What API Pagination Is

Pagination is how an API limits how much data it returns in a single response, splitting a large dataset into pages you retrieve one request at a time rather than getting everything back at once. Almost every API with any meaningful amount of data implements this, and if your scenario is not built to account for it, you will simply get the first page's worth of records and nothing else, with no error telling you data is missing.

Why APIs Paginate Data

A single response containing thousands of records would be slow to generate, slow to transmit, and unwieldy for both the API and whatever is consuming it. Pagination keeps individual responses fast and manageable, at the cost of requiring the consumer, your Make scenario, to ask for each page explicitly rather than getting everything in one call.

Offset Pagination

The most common pattern uses two parameters, offset and limit. Limit sets how many records to return per page, offset sets how many records to skip from the beginning of the dataset. The first request uses offset zero, and each subsequent request increases the offset by the limit: request one skips zero records and gets the first 100, request two skips 100 and gets the next 100, and so on. You stop once a response returns fewer records than the limit, or an empty result, either of which signals you have reached the end.

Page-Based Pagination

Similar in spirit, but instead of tracking a raw offset, the API takes a page number directly, ?page=1&limit=20. You increment the page number on each request rather than calculating an offset, and stop once you have retrieved the total number of pages the API reports, or once a page comes back empty.

URL-Based Pagination

Some APIs, GitHub and GitLab among them, return the exact URL for the next page directly in the response, commonly in a Link header. Rather than calculating anything yourself, you extract that URL and use it as-is for the next request. This is the simplest pattern to implement correctly since there is no offset or page arithmetic to get wrong, just following the link the API hands you.

Cursor Pagination

APIs like Stripe, Notion, Slack, and Airtable use a cursor or token-based approach instead of a numeric offset. Each response includes a next_cursor or similarly named token, which you pass into the next request to get the following page. You stop once the returned cursor is empty or absent, which signals there is no further data. Cursor pagination is generally more resilient than offset-based pagination against data changing mid-pagination, since it tracks a specific position rather than a numeric count that can drift if records are added or removed while you are paginating through them.

Building Pagination in the HTTP Module

Make's native HTTP module supports built-in pagination for offset-based and page-based patterns directly in its configuration, which handles simpler cases without needing to build the loop manually. For anything the built-in pagination cannot handle cleanly, most notably a cursor that comes back as a complex nested object rather than a simple string or token, the built-in module can fail to serialize it correctly into the next request, and you need to build the loop yourself.

The manual pattern: a Repeater module driving iteration, an HTTP module inside it making the actual request using the current offset, page, or cursor value, and a Router or filter checking the response after each call to decide whether to continue or stop. Since Make does not have a native while loop, this Repeater-plus-conditional-stop combination is the standard way to express "keep going until the API tells you to stop." Store the running offset or cursor value using Make's Variables module or a Data Store between iterations, since each loop pass needs the value from the previous response to correctly build the next request.

Common Pagination Mistakes

Not checking the API's actual pagination style before building. Offset, page, and cursor patterns look similar on the surface but require different logic. Read the API documentation first rather than guessing from response shape alone, since guessing wrong wastes real build time.

No hard stop condition. Without a maximum iteration limit on the Repeater as a safety net, a pagination bug that never correctly detects "no more data" can loop indefinitely, burning through operations rapidly. Set a sane maximum alongside the actual stop condition based on the API's response.

Ignoring rate limits during pagination. Rapid sequential requests during a pagination loop are exactly the kind of pattern that triggers a 429, covered in Make.com Rate Limit 429 Errors. A Sleep module between iterations, even a short one, is cheap insurance against hitting a limit mid-loop and having to restart.

Testing only with small datasets. A pagination loop that works perfectly for two pages can still have a subtle bug in its stop condition that only shows up on page fifteen. Test with a small page size deliberately, two to five records per page, so you can verify the loop terminates correctly across several iterations without burning through hundreds of operations during testing.

If you are building a Make.com scenario that needs to pull a full dataset from a paginated API rather than just the first page, that is exactly the kind of scenario work I take on for clients. Book a free 30-minute call and bring the API you are working with, and we will build the pagination loop correctly.

Frequently Asked Questions

What is pagination in Make.com?

It refers to handling an API that splits its data across multiple pages rather than returning everything in one response. A Make scenario needs explicit logic to request each page in sequence, or it will only retrieve the first page's worth of data.

How do I paginate an API in Make?

For offset or page-based APIs, Make's native HTTP module often handles it directly through its built-in pagination settings. For more complex cases, especially cursor-based pagination with nested tokens, build a manual loop using a Repeater, an HTTP module, and a stop condition checked after each request.

What is cursor pagination?

A pagination method where each API response includes a token identifying the next page's starting point, rather than a numeric offset or page number. You pass that token into the next request and stop once no further cursor is returned.

How do I paginate an offset API in Make?

Track a running offset value, starting at zero, and increase it by your page limit after each successful request. Stop once a response returns fewer records than the limit or comes back empty, either of which signals the end of the dataset.

How do I stop pagination at the last page?

Check the response after each request for a signal that no more data remains: an empty result set, fewer records than the limit, a null or missing cursor, or a total page count you have already reached, depending on which pagination style the API uses.

Why is my Make pagination returning duplicate records?

Usually an offset or page calculation error, incrementing incorrectly between iterations so the same range of records gets requested more than once. Double-check the arithmetic driving your offset or page number against exactly what the API expects for each subsequent request.

If you would rather have this built than build it, I take on Make.com scenario architecture work through Fiverr.