Automation: Runner, Newman & Monitors

Collection Runner & Data Files

Data-driven runs iterate the whole collection once per row of a CSV/JSON file, keeping the request/assertion logic in one place — adding a new test case means adding a data row, not duplicating a request.

email,expectedStatus
valid@example.com,201
not-an-email,400
,400

# In the request body: {{email}}
# In a test script: pm.test('status matches', () => {
#   pm.response.to.have.status(Number(pm.iterationData.get('expectedStatus')));
# });

Newman (CI)

npm install -g newman

newman run my-collection.json \
  -e staging-environment.json \
  --reporters cli,junit \
  --reporter-junit-export results.xml

# Exits non-zero on any failed test assertion — CI systems treat that
# as a failed build step automatically, no extra glue code needed.

Execution Order

Pre-request scripts run collection-level first, then folder-level, then the request's own. Test scripts run in reverse — the request's own tests first, then folder, then collection — letting shared setup/teardown wrap individual request behavior.

Mock Servers & Monitors

A Mock Server returns predefined example responses matched by request pattern — useful for frontend development before a real backend exists, but generally stateless: a POST that "creates" something won't be reflected in a later GET, which can mask integration bugs a real backend would surface. A Monitor runs a collection on a schedule (e.g. hourly) to continuously verify an API is healthy, alerting on failure — a lightweight uptime check with no separate infrastructure.

Secrets

Never hardcode API keys/tokens directly in a request — sharing or exporting the collection leaks them in plaintext JSON. Use an environment variable, ideally typed "secret" so Postman masks it in the UI.