Many API scenarios require sending similar requests with different data values, such as different user types, boundary values, or error cases. Manually changing fields repeatedly is error-prone and slow. Postman’s data-driven testing features let you feed external data files into collection runs to cover multiple scenarios automatically.
Collection Runner and Data Files
The Postman Collection Runner can execute a collection multiple times using data from a CSV or JSON file. Each row or object represents one iteration, and Postman exposes the values as variables. Your requests and scripts can then refer to {{variableName}} to customise behaviour per iteration.
# Example CSV data file for creating customers
name,email,age,plan
"Alice Tester","alice@example.com",30,"premium"
"Bob Example","bob@example.com",18,"basic"
"Cara Edge","cara@example.com",65,"senior"Within scripts, you can access iteration data using the pm.iterationData API. This allows you to perform assertions that depend on the input, such as verifying that certain requests succeed while others fail with expected errors.
Designing Effective Data Sets
Good data sets focus on meaningful variations rather than random values. Use partitioning and boundary analysis to choose rows that stress important conditions. Keep files readable and version-controlled so changes are tracked along with tests.
Common Mistakes
Mistake 1 — Hard-coding test values across many requests
This makes updating and extending coverage tedious.
❌ Wrong: Copy-pasting similar requests with different payloads instead of using data files.
✅ Correct: Move variable data into CSV or JSON and reference it in a single collection.
Mistake 2 — Using random, unlabelled values in data sets
Such data is hard to reason about when failures occur.
❌ Wrong: Including many rows with no clear purpose or pattern.
✅ Correct: Design rows to represent specific conditions and document their intent.