Postman Workflows
Postman turns raw API calls into reusable collections with variables, environments, JavaScript test scripts and a runner. Chain requests so one response feeds the next, then run the same collection in CI with Newman.
What is this?
Postman organizes API calls into collections: requests grouped in folders, parameterized with variables, and extended with JavaScript pre-request and test scripts. Environments swap base URLs, tokens and credentials between dev, staging and prod without touching the requests. Because collections are runnable files, the same workflows that document the API also regression-test it.
Why do you need it?
- Collections package the entire API surface into shareable files a whole team can import and run.
- Environments swap base URLs, tokens and credentials between dev, staging and prod without editing requests.
- Test scripts run JavaScript assertions after every response, so collections double as executable documentation.
- The Collection Runner and Newman execute the same flows in CI, turning Postman into a real test harness.
- Pre-request scripts generate signatures, timestamps or tokens before each request is sent.
Mental model
A flight checklist
A Postman collection
Pilots run the same numbered checklist every flight, ticking each item in order. A collection encodes the same discipline: every request, assertion and handoff between steps is scripted, repeatable, and can be run by anyone on the crew.
How it works
- Design a request in Postman — method, URL, params, headers and body — stored inside a collection folder.
- Define environments with variables for baseUrl, token and ids so the same request runs anywhere.
- Attach pre-request and test scripts written in JavaScript to prepare data and assert on results.
- Use pm.response.json() and pm.environment.set() to extract values from one response and feed the next request.
- Run the whole collection in the Runner or via the Newman CLI and publish a pass/fail report.
A Postman workflow: request scripts extract values that later requests consume.
Key commands
npm install -g newmanInstall the Newman CLI so collections can run headless in CI.
newman run orders.postman_collection.json -e staging.postman_environment.jsonRun a collection against a specific environment.
✔ auth (200)\n✔ create order (201)\n┌─────────────────────────┐\n│ iterations: 1 │\n│ assertions: 4/4 passed │\n└─────────────────────────┘
newman run orders.postman_collection.json --folder authRun only one folder of a collection, useful for fast targeted checks.
newman run orders.postman_collection.json --env-var "token=abc123"Override an environment variable for a single run.
newman run orders.postman_collection.json --reporters cli,html --reporter-html-export report.htmlGenerate an HTML report alongside the CLI output for publishing.
Examples
Login, extract a token, and reuse it
// ---- Pre-request script on the login request ----pm.environment.set("requestTime", new Date().toISOString()); // ---- Response body from POST /auth/login ----// { "token": "eyJhbGciOi...", "expiresIn": 3600 } // ---- Test script on the login request ----const json = pm.response.json(); pm.test("status is 200", function () { pm.response.to.have.status(200);}); pm.test("token is present", function () { pm.expect(json).to.have.property("token");}); pm.environment.set("accessToken", json.token); // ---- Header on every later request ----// Authorization: Bearer {{accessToken}}The test script asserts the login response, then stores the token with pm.environment.set. Later requests reference {{accessToken}} in their Authorization header. When the token expires you rerun login first — the same variable is refreshed and every downstream request follows.
In production
- Teams version-control exported collections and run them via Newman as smoke tests on every deploy.
- New developers run the collection against staging to learn the API hands-on instead of reading docs.
- Partner teams consume a published collection as the source of truth for how to call the API.
- Postman Monitors schedule collections on an interval to alert on endpoint failures without a custom agent.
Best practices
- Store secrets in environments, never inside request bodies, and keep sensitive environment files out of git.
- Write one focused assertion per pm.test so a failing test names exactly what broke.
- Chain data with variables instead of copy-pasting hard-coded ids and tokens.
- Keep collections modular — one folder per resource or feature, with auth handled by a shared login request.
- Add an auth pre-request script that refreshes a token so long runs do not fail from expiry.
Common mistakes
- Hard-coding a manually copied token, then wondering why the collection fails an hour later.
- Cramming a request with dozens of assertions that are impossible to triage when one fails.
- Committing the production environment file with live secrets into the repository.
- Assuming a green run means the API is correct — Postman only checks what you actually assert.
Common issues
ReferenceError: token is not definedThe variable was never set, or it lives in a different scope than the one in use.
Run the login request first, or set the variable at environment or collection scope, then check the Console.
401 in collection runs but 200 when tested manuallyThe runner is using a different environment, or the stored token expired mid-run.
Confirm the environment selected in the runner matches, and add a token-refresh pre-request script.
Newman: ENOENT, no such fileThe collection path is relative to a different working directory in CI.
Use an absolute path or set the working-directory of the CI job before invoking newman.
Debugging tips
- Open View → Show Postman Console to see the exact request, response and timing of any call.
- Check the Test Scripts tab for runtime errors — a typo in a variable name silently skips assertions.
- Add console.log() calls in pre-request and test scripts to inspect variable values mid-flow.
- Run a single failing request in isolation with the environment selected before running the whole suite.
Interview checkpoint
Hands-on lab
- Create a collection and an environment with variables
- Write a test script that extracts a token from a login response
- Reference the token from a later request header
- Run the flow in the Runner and then headlessly with Newman
Chain Login to an Authenticated Request
30 min · beginner
Quick quiz
Which Postman scope is designed to hold environment-specific values like baseUrl and API keys?
pm.response.to.have.status(200) is JavaScript that runs after the request completes.
A 40-request collection run fails at request 10 with 401. Which cause is most likely?
Cheat sheet
newman run col.jsonRun a collectionnewman run col.json -e env.jsonRun with an environmentnewman run col.json --folder authRun one foldernewman run col.json --bailStop at first failurenewman run col.json --reporters junit,htmlEmit CI-friendly reportspm.test('name', fn)Define an assertion blockpm.response.to.have.status(200)Assert the status codepm.response.json()Parse the response bodypm.environment.set('k', v)Persist a value for later requestspm.variables.get('k')Read any scoped variable