Fetching every page when a polled API returns records in chunks.

Overview

Many APIs return long lists a page at a time rather than all at once. Pagination tells the connector how to keep requesting the next page until it has everything, so a polling trigger picks up all new records instead of just the first page. You configure it in the Pagination Config section of a polling trigger's HTTP Request tab — it isn't part of an action's request definition. When configured, the platform issues the follow-up requests automatically, tracking where it is between calls — you don't loop manually.

Pagination strategies

Under Configuration Type you choose the strategy that matches how the API paginates:

• Offset Based (the default) — the API takes a starting offset and a page size; the connector advances the offset by the page size each call.

• Cursor Based — the API returns a "next" token in each response; the connector carries it forward and sends it on the next request until there's no more.

• Page Based — the API takes a page number; the connector increments the page each call.

• Custom Based — for anything that doesn't fit the above.

For offset, cursor, and page you also set a Limit (the page size, default 10). Pick the one the API documents; offset, page, and cursor cover most REST APIs.

Putting the page position into the request

Once a strategy is chosen, the current page position becomes available as variables you insert into the request — type {{ in the URL, a query parameter, a header, or the body, and pick from the Cursor group: the limit, plus the offset, page, or cursor value (matching your strategy). For example, an offset API's query parameters would carry the offset and limit variables; the connector fills in the advancing values on each call. This is what lets a single trigger definition walk an arbitrarily long list.