It would help if the Airtable node’s Search Records operation supported manual pagination through Airtable’s pageSize and offset parameters.
My use case
We use a self-hosted n8n instance to synchronize a large and growing Airtable dataset containing more than 40,000 relatively large records .
We need the complete dataset, so we currently have to enable Return All . This makes the execution very resource-intensive: it is slow, difficult to test, and can cause our n8n instance to crash before the synchronization completes.
Being able to retrieve and process one page at a time would make this workflow much more reliable. Each page could be processed before requesting the next one, following a pattern similar to Loop Over Items , without asking the Airtable node to retrieve the entire dataset at once.
Current limitation
Airtable’s API supports cursor-based pagination: it accepts pageSize, returns an offset when another page is available, and accepts that offset in the following request.
The n8n Airtable node handles pagination internally when Return All is enabled. However, when Return All is disabled, it only returns a limited set of records and does not expose the next-page offset. A workflow therefore cannot request the following page using the dedicated Airtable node.
This can be implemented manually with an HTTP Request node, but that means rebuilding behavior that belongs naturally in the Airtable integration. Native pagination would be clearer, more maintainable, and easier to use.
Requested behavior
When Return All is disabled, the Airtable node should allow users to:
configure the page size;
provide an offset returned by the previous execution;
receive the next-page offset in the output when more records are available;
stop the loop when the last page returns no offset.
This would allow large tables to be synchronized in controlled batches.
Resources
Airtable pagination documentation:
Implementation PR:
master ← HermanPierre:airtable-node-search-pagination-options
opened 02:57PM - 03 Sep 26 UTC
## Summary
The Airtable `record:search` operation could only fetch everything (… "Return All") or a single capped request with no way to continue — the [list records API](https://airtable.com/developers/web/api/list-records) pagination parameters were not exposed, and the response's `offset` token was discarded, making page-by-page fetching impossible.
This PR adds the missing pagination support (node version 2.3):
- **Page Size** option — sent as the `pageSize` query parameter, controls how many records each API request/page returns (1–100). Also respected by the "Return All" batching, which previously hardcoded 100.
- **Offset** option — sent as the `offset` query parameter; accepts the pagination token from a previous run to fetch the next page.
- When **Return All** is disabled and more records are available, the response's `offset` token is now included on each output item, so it can be fed back into the Offset option to fetch the next page. The request is capped via `pageSize` instead of `maxRecords`, because Airtable omits the next-page token once `maxRecords` is reached.
Since the output shape changes (new `offset` field), the new behavior and options are gated behind node version 2.3 (`@version` display conditions). Existing workflows on ≤2.2 behave exactly as before; 2.3 is the new default version.
> This PR supersedes #33437 (closed). It addresses the review feedback from that PR: the page size option is read once (dead `qs.pageSize` assignment removed), and test coverage now includes the last page (no `offset` in output), the download-attachments path keeping the `offset`, and an explicit 2.2 check that the response `offset` is not forwarded.
## How to test
1. Add an **Airtable** node (version 2.3), operation **Search**, pointing at a table with more than 100 records.
2. Disable **Return All**, and set **Options → Page Size** (e.g. 50).
3. Execute: each output item contains an `offset` field.
4. Copy that value into **Options → Offset** and execute again: the next page is returned. On the last page, `offset` disappears from the output.
5. Loop workflow: connect the node's output through a **Limit** node (max 1 item) into an **If** node checking that `{{ $json.offset }}` exists, and loop the true branch back into the Airtable node with Offset set to `{{ $json.offset || '' }}` — it fetches all pages and stops on the last one.
6. Regression: a node pinned to version ≤ 2.2 shows no new options and produces unchanged output.
Unit tests cover the new query parameters, the `min(limit, pageSize)` capping, the offset field in the output for 2.3, and the unchanged 2.2 output.
## Related Linear tickets, Github issues, and Community forum posts
Supersedes #33437.
## Review / Merge checklist
- [x] I have seen this code, I have run this code, and I take responsibility for this code.
- [x] PR title and summary are descriptive. ([conventions](../blob/master/.github/pull_request_title_conventions.md))
- [ ] [Docs updated](https://github.com/n8n-io/n8n-docs) or follow-up ticket created.
- [x] Tests included.
- [ ] PR Labeled with `Backport to Beta`, `Backport to Stable`, or `Backport to v1` (if the PR is an urgent fix that needs to be backported)
<a href="https://cubic.dev/pr/n8n-io/n8n/pull/37766?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
The PR introduces these options in Airtable node version 2.3 while preserving the behavior of workflows using version 2.2 or earlier. It includes tests for page size and offset handling, the final page, downloaded attachments, and backward compatibility.
It also incorporates the review feedback from the earlier attempt:
master ← HermanPierre:airtable-node-search-pagination-options
opened 09:41AM - 02 Jul 26 UTC
## Summary
The Airtable `record:search` operation could only fetch everything (… "Return All") or a single capped request with no way to continue — the [list records API](https://airtable.com/developers/web/api/list-records) pagination parameters were not exposed, and the response's `offset` token was discarded, making page-by-page fetching impossible.
This PR adds the missing pagination support (node version 2.3):
- **Page Size** option — sent as the `pageSize` query parameter, controls how many records each API request/page returns (1–100). Also respected by the "Return All" batching, which previously hardcoded 100.
- **Offset** option — sent as the `offset` query parameter; accepts the pagination token from a previous run to fetch the next page.
- When **Return All** is disabled and more records are available, the response's `offset` token is now included on each output item, so it can be fed back into the Offset option to fetch the next page. The request is capped via `pageSize` instead of `maxRecords`, because Airtable omits the next-page token once `maxRecords` is reached.
Since the output shape changes (new `offset` field), the new behavior and options are gated behind node version 2.3 (`@version` display conditions). Existing workflows on ≤2.2 behave exactly as before; 2.3 is the new default version.
## How to test
1. Add an **Airtable** node (version 2.3), operation **Search**, pointing at a table with more than 100 records.
2. Disable **Return All**, and set **Options → Page Size** (e.g. 50).
3. Execute: each output item contains an `offset` field.
4. Copy that value into **Options → Offset** and execute again: the next page is returned. On the last page, `offset` disappears from the output.
5. Loop workflow: connect the node's output through a **Limit** node (max 1 item) into an **If** node checking that `{{ $json.offset }}` exists, and loop the true branch back into the Airtable node with Offset set to `{{ $json.offset || '' }}` — it fetches all pages and stops on the last one.
6. Regression: a node pinned to version ≤ 2.2 shows no new options and produces unchanged output.
Unit tests cover the new query parameters, the `min(limit, pageSize)` capping, the offset field in the output for 2.3, and the unchanged 2.2 output.
## Related Linear tickets, Github issues, and Community forum posts
## Review / Merge checklist
- [ ] I have seen this code, I have run this code, and I take responsibility for this code.
- [x] PR title and summary are descriptive. ([conventions](../blob/master/.github/pull_request_title_conventions.md))
- [ ] [Docs updated](https://github.com/n8n-io/n8n-docs) or follow-up ticket created.
- [x] Tests included.
- [ ] PR Labeled with `Backport to Beta`, `Backport to Stable`, or `Backport to v1` (if the PR is an urgent fix that needs to be backported)
🤖 PR Summary generated by AI
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---
<a href="https://stagereview.app/n8n-io/n8n/pull/33437">
<picture>
<source media="(prefers-color-scheme: dark)" srcset="https://stagereview.app/assets/gh-open-in-stage-dark.svg">
<img src="https://stagereview.app/assets/gh-open-in-stage-light.svg" alt="Open in Stage">
</picture>
</a>
<a href="https://cubic.dev/pr/n8n-io/n8n/pull/33437?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
Are you willing to work on this?
Yes. I have already implemented the proposed behavior in PR #37766 and am willing to address additional review feedback.