Make.com Pagination How to Fetch All Data From an API

You set up a Make.com scenario, it runs without errors, but you’re only getting the first 100 records out of thousands. That’s Make.com pagination at work, and if you don’t handle it, your scenario silently processes a fraction of your data.

I spent a lot of time figuring this out across different APIs. Every service does pagination slightly differently, and building the right loop in Make isn’t always obvious. That frustration eventually pushed me to build a ready-made toolkit, but more on that later.

What Pagination Is and Why APIs Use It

APIs split large datasets into pages to avoid overloading servers. They return 50 or 100 records at a time and give you a way to request the next batch, through a token, an offset, or a page number.

Fine in theory, but only if your Make scenario knows how to follow those pages. If not, you get page one and nothing else.

Types of Pagination in Make.com

Before building the loop, identify which pagination style the API uses.

Offset pagination takes offset and limit parameters. You increment the offset by the limit on each iteration, stopping when the returned items are fewer than the limit.

Page-based pagination uses a page number instead. You advance the counter until you hit totalPages from the response or receive an empty results array.

Cursor pagination, used by Notion, Airtable, Meta APIs, returns a next_cursor or next_page_token in each response. Pass it into the next request. Stop when the cursor comes back empty.

How to Set Up Pagination in Make Step by Step

The structure is always the same: a loop with a state variable, an HTTP module making the API call, and a filter deciding whether to continue.

1. Store your offset or cursor

Use Make’s Variables module or a Data Store to hold the current offset or cursor between iterations.

2. Pass the variable into the HTTP request

Reference the stored value as a query parameter:

{{1.offset}}

For cursor pagination:

{{if(1.next_cursor; 1.next_cursor; "")}}

3. Loop using Repeater and a conditional Router

Make doesn’t have a native while loop. The standard approach combines a Repeater with a Router that checks the stop condition after each API call.

4. Set the stop condition correctly

• Offset: length(items) < limit
• Page-based: currentPage >= totalPages
• Cursor: isEmpty(next_cursor)

A wrong stop condition either cuts the loop short or runs it forever.

Common Mistakes

Forgetting to reset the variable. If the scenario runs repeatedly and you store the offset in a Data Store, reset it at the start of each run.

Trusting length < limit blindly. Some APIs return exactly limit items on the last page. Check how the specific API signals the end, has_more: false, an empty array, or something else.

Ignoring rate limits. Pagination means rapid sequential API calls. Add a Sleep module with a 1-2 second pause if the API documents rate limits.

💡 Test with a tiny limit, 2-5 records, first so you can verify the loop logic without burning through hundreds of operations.

Ready-Made Patterns

Every project means a slightly different API and rebuilding the loop from scratch. I built the Make.com API Pagination Toolkit to stop doing that, a set of blueprints for offset, page-based, and cursor pagination. Import, remap your variables, done.

If you also need to process the returned arrays, the Make.com iterator guide pairs well with this.

Get the API Pagination Toolkit on Gumroad

Summary

Make.com pagination comes down to knowing your API’s pagination style, storing state between iterations, and getting the stop condition right. Once you have a working pattern, reusing it across projects takes minutes.

If you’d rather skip the trial and error, the toolkit gives you a solid starting point, just swap in your variables and go.