Collection Runner

Analogy categoryAnalogies

What Is the Collection Runner?

The Collection Runner is a built-in Postman feature that executes every request in a collection automatically, in order, without you clicking Send on each one individually. As each request fires, its associated test scripts run immediately after, and Postman tallies a running pass/fail count so you can see the health of an entire API workflow in one pass instead of testing endpoints one at a time.

🏏

Cricket analogy: It's like a full net session where a coach runs a bowler through a set over of deliveries against a fixed line-up, checking each ball against a target instead of bowling one delivery and stopping.

Configuring a Run: Iterations, Delay, and Data Files

Before starting a run, you configure how many Iterations the whole collection should repeat, an optional Delay (in milliseconds) between individual requests to avoid hammering a server or hitting rate limits, and optionally a bound data file that feeds different values into each iteration. These settings turn a simple linear replay into a controllable, repeatable test execution.

🏏

Cricket analogy: Setting iterations is like telling a bowling machine to fire exactly 50 balls at a fixed pace, and adding delay is like the umpire enforcing a gap between overs so the batsman can reset.

Data-Driven Testing with CSV and JSON Files

Binding a CSV or JSON data file to a run means each iteration pulls the next row of values and exposes them as variables, either through {{columnName}} syntax directly in requests or via pm.iterationData.get("columnName") in scripts. This lets you test the same request logic against dozens of different inputs — usernames, IDs, expected status codes — without duplicating requests.

🏏

Cricket analogy: Binding a CSV of player names to a run is like a scorer feeding a different batsman's name into the scoreboard for each ball faced, so every iteration reflects a new player automatically.

javascript

// pm.iterationData.get() pulls the current row from the bound CSV/JSON data file
const expectedStatus = pm.iterationData.get("expectedStatus");
const userId = pm.iterationData.get("userId");

pm.test(`Status code is ${expectedStatus} for user ${userId}`, function () {
    pm.response.to.have.status(Number(expectedStatus));
});

// users.csv
// userId,expectedStatus
// 101,200
// 102,404
// 103,200

Reading Run Results and Exporting Reports

After a run finishes, Postman shows a summary view listing every request's pass/fail status, individual assertion results, and response times across all iterations. You can drill into any failed assertion to see the exact expected-vs-actual mismatch, and export the full results as a JSON report for archiving or feeding into another dashboard.

🏏

Cricket analogy: The run summary is like a full scorecard tallying runs, wickets, and strike rate after the innings, letting a coach review the whole performance at a glance.

You can trigger the equivalent of a Collection Runner run headlessly via Newman (newman run collection.json -d data/users.csv -n 3) for the exact same data-driven iteration behavior in CI, without opening the Postman desktop app.

Environment and global variables set with pm.environment.set() in one iteration persist into the next unless you explicitly pm.environment.unset() them — a leftover auth token from iteration 2 can silently make iteration 3 pass a test it should have failed.

Collection Runner executes every request in a collection sequentially, running each request's test scripts and tallying pass/fail results.
Iterations control how many times the whole collection repeats; Delay adds a pause (ms) between individual requests.
Binding a CSV or JSON data file lets each iteration pull a fresh row of variables via {{variableName}} or pm.iterationData.get().
The run summary shows per-request pass/fail counts, response times, and can be exported as a JSON report for later review.
Variables set during one iteration persist into later iterations unless explicitly unset, which can mask real failures.
Newman provides the same iteration/data-file behavior from the command line for CI use.