Automation/ Postman / Newman
API · Grad, Junior & Senior

Postman / Newman

The industry standard for API testing — a GUI for exploring endpoints and a CLI runner for automating them in CI/CD.

Grad Junior Senior ISTQB CTAL-TAE ~8 min read

1 The Hook — The Revenue NZ Integration Leak

A dev team in Wellington was integrating their platform with an Revenue NZ (Revenue NZ) API. They were manually copy-pasting OAuth tokens from their browser into their code to test. Late one Tuesday, a developer accidentally committed a live production token to a public GitHub repository. Within minutes, the token was compromised, and the team had to shut down their integration for an emergency security reset.

Postman's Environments would have prevented this. By using variables for tokens and keeping sensitive values in the "Current Value" field (which isn't synced to the cloud), the team could have tested securely and automated their token refresh. Postman isn't just about sending requests; it's about managing them safely.

2 The Rule — Never Hardcode; Always Variable

Use Environments for URLs and credentials. Use Collections to group related requests. Use Scripts to automate validation.

If you see a URL like https://api.resync.nz in a request, replace it with {{baseUrl}}. This allows you to switch from Dev to Production with a single click.

3 The Analogy — The Filing Cabinet

Analogy

The Recipe Box.

Sending an API request manually is like cooking a meal from memory. It works once, but it's hard to repeat exactly. Postman is a Recipe Box (Collections). Each card (Request) has the ingredients (Headers/Body) and the instructions (Scripts). Environments are like different kitchens: you can use the same recipe in your home kitchen (Dev) or a professional restaurant (Production) just by changing your tools.

Senior engineer insight

The moment a Postman collection stops being a personal scratch pad and becomes team property is when the investment in proper Environment management pays off. I've seen teams where every tester ran the same collection against a shared staging environment with hardcoded credentials — the first time someone's test mutated shared state (deleted a record mid-run for a colleague), the blame game started. Separating environment files per tester, with personal sandboxed data, turned those daily conflicts into non-events.

The most common mistake: treating Newman in CI as a second-class citizen by never actually running it locally — teams discover "Newman-only" failures at 2am when the pipeline breaks.

4 Watch Me Do It — PostNZ Address Search

Scenario: Testing an PostNZ address lookup API to ensure it returns the correct suburb for a given post code.

// 1. Send the Request: GET {{baseUrl}}/address/search?q=6011

// 2. The Test Script (JavaScript)
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response is JSON", function () {
    pm.response.to.be.withBody;
    pm.response.to.be.json;
});

pm.test("First result is in Wellington", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.results[0].city).to.eql("Wellington");
    pm.expect(jsonData.results[0].postcode).to.eql("6011");
});

From the field

A Wellington fintech team building an open banking integration with one of the NZ big four banks assumed their Postman collection was the source of truth for API contracts. They ran it locally, all green, signed off, deployed. The CI pipeline used Newman — and it failed immediately because the collection had been exported from a version of Postman that serialised pre-request scripts differently, causing silent script failures that the GUI had masked. They'd never verified that what Newman ran matched what they saw in the GUI.

The fix was a fifteen-minute discipline change: run newman run collection.json -e env.json --bail as a mandatory step before any "passed in Postman" sign-off. The lesson generalises everywhere — if your CI runner and your GUI aren't tested against the same artefact on the same cadence, you have two test suites pretending to be one.

5 Decision Tool — Why Postman?

✅ Choose Postman for...

  • Manual API exploration and debugging
  • Building a "living documentation" collection
  • Fast API smoke tests for CI/CD
  • Teams where non-coders need to run tests

❌ Choose Programmatic (Playwright/RestAssured) for...

  • Extremely complex test data logic
  • Reusing common helper functions across 100s of tests
  • Deep integration with UI tests (Shared state)
  • Massive data-driven suites with 1000s of rows

6 Common Mistakes

🚫 Initial Value vs. Current Value

Mistake: Putting an API Key in "Initial Value".
Why: "Initial Value" syncs to the Postman Cloud (and your team). "Current Value" stays local to your machine. Always use Current Value for secrets.

🚫 Not using pm.test()

Mistake: Just writing console.log() or raw JS in the test tab.
Why: Without pm.test(), Postman and Newman won't mark the test as passed or failed in your reports.

7 Now You Try — Setup

📦 Getting Started

Download the Postman Desktop app from postman.com. Once installed, try importing this public Resync API collection (if available) or create your first request to https://postman-echo.com/get.

To run your collections in CI, install Newman via npm:

npm install -g newman

Why teams fail here

  • Secret sprawl via Initial Value: Developers populate Initial Value with real tokens because it auto-fills — those values sync to Postman Cloud and leak across the team or into version-controlled environment exports.
  • Newman not in the pipeline until it's too late: Teams build and verify collections in the GUI for months, then bolt Newman onto a CI job at go-live — only then discovering that ordering dependencies, missing globals, or different Node versions break everything.
  • No chaining strategy for authenticated flows: Tests that need a login token first (OAuth, JWT) are written as standalone requests — when run as a collection the token-fetch step either doesn't exist or runs out of order, causing cascading 401 failures that look like API bugs.
  • Collections that document rather than assert: Requests are saved with no pm.test() blocks — the collection runs "green" in Newman because zero tests means zero failures, giving false confidence while regressions accumulate silently.

8 Self-Check

Q1. What is the difference between Postman and Newman?

Postman is the GUI (Visual tool) used to build and manually test APIs. Newman is the CLI (Terminal tool) used to run those same tests automatically in CI/CD pipelines.

Q2. How do I pass data from one request to another in Postman?

Environment Variables. In the test script of Request A, use pm.environment.set("myId", responseBody.id). In Request B, use {{myId}} in the URL or Body.

Key takeaway

A Postman collection with no pm.test() blocks isn't a test suite — it's a documentation tool that lies to your CI pipeline.

9 Interview Prep

"How do you secure sensitive data in Postman?"

Answer: "By using Environment Variables and carefully managing the Current Value vs Initial Value fields. Secrets should only be placed in the Current Value field, as it is stored locally and never synced to the Postman cloud or shared with the team. I also use .gitignore for any exported environment JSON files."