Can Postman’s Collection Runner automatically handle pagination across iterations?

Short answer

No. The Collection Runner has no built-in pagination support. It cannot follow next links, increment page parameters, or aggregate results across iterations on its own. Every iteration is an independent request execution driven by your iteration count or data file rows, and Postman 10.x ships no feature — announced or otherwise — that changes this. Any automatic pagination you get comes from scripts you write yourself.

What's confirmed vs. assumed

Confirmed behavior, stable across many Postman versions: the Runner re-executes the selected request(s) once per iteration, substituting data-file variables. It has no concept of "keep going until there's no next page." The assumption worth flagging: this is based on documented behavior up through Postman 10.x; verify against your installed version's release notes, since Postman's feature set evolves and this claim is marked for current verification.

How pagination actually gets done

There are two script-based patterns, and both are "custom logic" by your definition — there is no way around that.

Pattern 1: Loop one request with setNextRequest

In the request's Tests tab, extract the cursor or next-page indicator and re-run the same request until it's exhausted:

const body = pm.response.json();\n// accumulate this page's items\nconst collected = pm.environment.get(\"items\");\nconst items = collected ? JSON.parse(collected) : [];\npm.environment.set(\"items\", JSON.stringify(items.concat(body.results)));\n\nif (body.next_cursor) {\n    pm.environment.set(\"cursor\", body.next_cursor);\n    postman.setNextRequest(pm.info.requestName); // loop\n} else {\n    postman.setNextRequest(null); // stop\n}

The request URL references {{cursor}}. Run the collection once; the script drives the loop, not the iteration count.

Pattern 2: Data file with precomputed page numbers

If the API uses ?page=N and you know the page count, supply a JSON data file [{\"page\":1},{\"page\":2},...] and aggregate in the Tests script. This works but requires knowing the page count up front, which is often the thing you don't know.

Guardrails that matter

• Termination: if the API returns a malformed or repeating cursor, setNextRequest loops forever. Add an iteration cap, e.g. stop when pm.info.iteration exceeds a limit or track a counter variable.
• Rate limits: respect Retry-After / 429 responses; the Runner has a configurable delay between requests — set it rather than hammering the API.
• State reset: clear your accumulator variable (items) before each run, or a second run doubles your data.

Verification

Point the request at a known paginated endpoint (or a mock server returning 3 pages), run via Collection Runner, and check the console log: each execution should show a distinct cursor/page value, and the run should stop after the last page. Export the run results and confirm the accumulated variable contains the union of all pages with no duplicates.

One detail that changes the recommendation

Which pagination style does your API use — cursor/next URL, offset/limit, or page number? Cursor-based APIs fit Pattern 1 cleanly; offset-based APIs can hit deep-offset performance problems where a different retrieval strategy (bulk export endpoint, webhooks) may beat Runner scripting entirely.