What it is
Actions of a Flows application can now declare how their endpoint returns pages when the response contains many records. Until now an action always returned whatever a single request to the target API produced, so only the first page of a large collection reached Flows. With a pagination configuration, Flows knows which request parameters control paging and where to read the value of the next page from, and can therefore walk through all pages of the endpoint.
Pagination is configured per action, is optional, and is only offered for actions whose response is a list of records (an array response). For any other action the option is not available.
Where to find it
Open a Flows application version → Actions → the action → the outputs step, and use Configure Pagination. The button opens the Pagination modal, which contains three parts:
1. the pagination strategy (and, for offset, the model),
2. the mapping between the strategy and the action's own inputs (request parameters) and outputs (response fields),
3. a Run test area that executes one real request against the endpoint with the configuration currently on screen.
Once a configuration is saved, the outputs step shows a short summary of it, for example "Offset pagination configured (limit + offset)".
Supported strategies
1. Offset pagination
The endpoint fetches results by position. Two equivalent models are supported:
- Limit + Offset — the number of records per page and the number of records to skip. You map Input parameter for Page Limit and Input parameter for Page Offset to the action inputs the API expects.
- Page size + Page number — the same paging expressed as a page size and a page index. You map Input parameter for Page Size and Input parameter for Page Number.
2. Keyset pagination
The endpoint continues from the last record it returned (for example id > 100), which avoids skipped or duplicated records. You map:
- Input parameter for Keyset — the request parameter the API expects,
- Value for Keyset — the response field holding the id or timestamp of the last record of the page.
3. Cursor-based pagination
The endpoint returns a token that must be sent back to fetch the next page. You map:
- Input parameter for Cursor — the request parameter carrying the token,
- Value for Cursor — the response field where the API returns the next cursor.
Rules and validation
- Pagination can only be saved for an action with a list (array) response.
- Only the action's existing inputs can be selected as pagination parameters; only simple (leaf) response fields can be selected as pagination values — objects and arrays are rejected.
- Response fields are stored without the leading $.body. prefix, so the selectors show plain field names.
- Only the section of the selected strategy is stored, so switching strategy never leaves behind settings from the previous one.
- The same input cannot be picked twice inside one offset configuration: an input already used by one selector is hidden in the other.
- Save is enabled only when the configuration is complete and differs from the one the modal was opened with. The values typed in the test area are not part of the configuration and never enable Save.
- Saving pagination on an already published action moves it back to Renewed, so the change is picked up on the next publish. The configuration is sent to Flows together with the rest of the action when the action is published.
Testing a configuration before saving
Run test performs a single real request to the action's endpoint using the configuration currently selected, so paging parameters can be verified before they are saved. The area shows the method and the preview URL, one input field per pagination parameter (prefilled with the values of the last action test), and after the run the HTTP status, the response payload — with a Copy JSON action — or the error message.
How the request is built:
- the pagination parameters take the values typed in the test area;
- every other input of the action is sent with its saved example value, so required parameters the test does not ask about (tenant, filters, path parameters, headers, body fields, …) are part of the request and the endpoint does not reject it;
- the user only sees and edits the inputs belonging to the pagination configuration.
The test is completely side-effect free: nothing is persisted. The saved examples, the stored test response, the generated outputs, the "tested" flag, the action status and any previously saved pagination configuration are all left untouched, so a test run cannot overwrite anything that was configured before. The configuration being tested does not need to be saved first.
A value is required for every pagination input before the test can run. If a required input of the action has no saved example value, it is not sent and the endpoint may answer with an error, which is displayed as the response of the test.
Error messages
| Configuration missing or incomplete | The pagination configuration is required. |
| Action does not return a list of records | Pagination can only be configured for actions returning a list of records. |
| Unknown strategy | The selected pagination strategy is not supported. |
| Unknown offset model | The selected offset pagination model is not supported. |
| Input not found on the action | The selected pagination input does not exist on this action. |
| Response field not found or not a simple value | The selected pagination output does not exist on this action or is not a simple value. |
| Test started with an empty pagination value | A value is required for every pagination input before running the test. |