Make.com API Pagination Patterns Toolkit What You Get Inside
You run a scenario. It returns 50 records. But the database has 4,000 — and nobody tells you. The scenario completes without an error, the data is incomplete, and you have no idea. This is the classic Make.com API pagination trap — and that’s exactly why I built the API Pagination Patterns Toolkit.
💡 If you’re new to pagination in Make, start with how Make.com pagination works and how to fetch all data from an API. This article builds on that.
Why Pagination in Make Is Painful
Most REST APIs don’t return all data at once. They split it into pages and expect you to fetch them one by one. Without a proper looping setup, you lose most of your data — silently, without any error.
The problem is that every API handles pagination differently. HubSpot uses a cursor. GitHub puts the next page URL in a response header. Others use an offset or a page number. Each requires a different setup in Make.
I used to build each scenario from scratch — reading docs, tuning conditions, testing edge cases. Hours every time. Then I realized I kept solving the same problems over and over. So I packaged everything into a toolkit.
The 4 Pagination Types the Toolkit Covers
These are the four main approaches REST APIs use:
| Pagination type | How it works | Example APIs |
|---|---|---|
| Page-based | You send page=1, page=2… | Pipedrive, many CRMs |
| Offset-based | You send offset=0, offset=50… | HubSpot (partial), Airtable |
| Cursor-based | API returns a token for the next page | HubSpot, Stripe, Shopify |
| Link header | Next page URL is in the HTTP response header | GitHub, GitLab |
Each type has a ready-to-use pattern in the toolkit — including the correct loop, stop condition, and output variable.
What’s Inside the Toolkit
The toolkit is a set of Make.com blueprints ready to deploy immediately. For each pagination type you get:
- A ready blueprint — import, copy, remap the URL and parameters
- A stop condition — the loop ends at the right moment
- An output variable — all data aggregated into a single array for further processing
- In-scenario comments — you know what to change and why
The most popular patterns:
- Page-based loop — basic pagination with automatic stop after the last page
- Offset incrementer — offset increases by page size until the API returns fewer records than
limit - Cursor extractor — cursor is extracted from the response and passed to the next iteration
- Link header parser — the
Linkheader is parsed and thenextURL is extracted
How to Use the Toolkit
- Import the blueprint that matches your API’s pagination type
- Copy the pattern into your scenario — or use it as a standalone subflow
- Remap the URL and parameters according to your API’s docs — the logic stays the same
You don’t need to understand every detail. Just know which pagination type your API uses — you’ll find that in the docs or in the first API response.
⚠️ If you’re working with complex business logic inside the loop, the Make Code module can process data directly in your scenario without extra credits.
Who Benefits Most From the Toolkit
The toolkit is for you if:
- You hit an API that returns data in pages and don’t know how to handle it
- You don’t want to spend hours finding the right configuration in documentation
- You need a reliable solution for a production scenario — not a prototype
- You build integrations for clients and want to deliver fast
FAQ
Does the toolkit work with any API? Yes — it covers the four most common pagination types. If your API uses something unusual, the patterns give you a solid base to customize.
Do I need a paid Make.com plan? You need an active Make.com account. The free plan is fine for testing; for production use I recommend Core or higher.
How long does setup take? For simple cases, 10-15 minutes — import, remap the URL, test. For more complex integrations, count on about an hour.
Stop Losing Data
API pagination isn’t complicated — it just needs the right logic. The toolkit gives you exactly that: ready, tested, and ready to deploy.