Postman / Newman
The most widely used API client in NZ teams. Build collections, write test scripts, and run them in CI with Newman.
Overview
Postman, launched in 2012, is the dominant API platform for building, testing, and documenting APIs. With over 20 million users worldwide, it is the default tool for API development in most software teams. Postman Collections allow teams to organise requests into folders, add pre-request scripts, write test assertions in JavaScript, and share everything via workspaces.
Newman is Postman's command-line collection runner, enabling CI/CD integration. A Postman collection exported as JSON can be executed by Newman in any pipeline, making it trivial to automate API regression tests.
What it's used for
Postman is essential for:
- API development and debugging: Send requests, inspect responses, and troubleshoot endpoints during development.
- Automated API regression: Write tests in Postman, then run them in CI via Newman on every commit.
- API documentation: Generate interactive documentation from collections that stays in sync with the API.
- Mock servers: Create mock APIs for frontend teams to work against before the backend is ready.
- Contract testing: Validate that API responses match expected schemas.
Pros & Cons
Pros
- Intuitive GUI that every developer already knows
- Collections are portable and version-controllable
- Newman enables headless CI execution
- Massive ecosystem: integrations with Jenkins, GitHub Actions, Azure DevOps
- Free tier is generous for small teams
Cons
- Not a code-based tool — tests live in Postman, not in your repo
- Collaboration friction: syncing collections across teams requires discipline
- Limited scripting power compared to REST Assured or code-based frameworks
- Performance testing is basic compared to k6 or JMeter
- Enterprise pricing escalates quickly for large teams
Platforms & Integrations
Postman runs on Windows, macOS, and Linux as a desktop app. It also has a web version. Newman runs anywhere Node.js runs.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Free | Free | 3 users, unlimited collections, basic features |
| Basic | $12/user/mo | Unlimited users, advanced collaboration, 10,000 API calls/mo |
| Professional | $29/user/mo | Private workspaces, IP whitelisting, 100,000 API calls/mo |
| Enterprise | Custom | SSO, audit logs, dedicated support, on-premise option |
NZ Context
Postman is ubiquitous in NZ software teams. Every junior tester and developer is expected to know how to send requests and write basic assertions. NZ government APIs (like data.govt.nz) often provide Postman collections as documentation. For NZ QA roles, "Postman experience" is frequently listed as a baseline requirement.
Alternatives
- Insomnia — Lighter alternative with strong GraphQL support and local storage.
- REST Assured — Code-based Java DSL for teams that want API tests in their codebase.
- Hoppscotch — Open-source, web-based alternative. Free and lightweight.
When to choose Postman
A quick decision guide for NZ teams evaluating API testing options.
| Choose Postman when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team has mixed technical backgrounds — developers and manual testers both need to touch API tests | Your team is Java-first and wants API tests living inside the same codebase as unit tests — use REST Assured instead | k6 — Postman covers functional correctness; k6 covers load and performance on the same endpoints |
| You need to stand up a mock server so a front-end team can develop against an unfinished backend | You are running hundreds of parallel API tests in CI with complex data pipelines — a code-based framework like Playwright API or Karate gives you more control | GitHub Actions or Azure DevOps — Newman slots into any pipeline and outputs JUnit XML that both platforms consume natively |
| You are onboarding a new API from a third-party vendor who provides a Postman collection as documentation | Budget is the primary constraint and the team is small — Hoppscotch or Insomnia give similar GUI capability at zero cost with no seat-count pressure | Pact — Postman validates live API behaviour; Pact enforces the contract between consumer and provider so both sides can change safely |
| Your CI platform is already Node-based and you want regression tests that require no additional language runtime | You need to test WebSocket, SSE, or other non-HTTP protocols — Postman's support here is thin; reach for a code-based tool | Swagger UI / OpenAPI — use the spec to generate an initial Postman collection automatically, then layer test assertions on top |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
pm.environment.set() is underused — it lets you build realistic end-to-end flows without a full E2E framework.The bottom line: Postman wins on speed of adoption and collaboration breadth — but only if you treat collections as team assets checked into source control and executed by Newman in CI, not as personal sandboxes that disappear when someone leaves.
Interview questions
Questions you are likely to get if you list Postman on your CV — with what interviewers are really testing for.
What is the difference between a Postman environment and a Postman collection?
What they’re really testing: Whether you understand how Postman separates configuration (environments) from behaviour (collections), and whether you can maintain a single collection that works across dev, staging, and production without hardcoding values.
Strong answer covers: A collection groups requests and test scripts; an environment stores variables like {{base_url}} and {{token}} that change per context. Mention switching environments at the top-right dropdown. Bonus: flag that credentials must never be hardcoded in a collection — relevant in NZ government and banking contexts where collections are shared across teams or exported to third parties.
When would you choose Newman over running tests directly in the Postman GUI?
What they’re really testing: Whether you understand the distinction between exploratory tooling and automated regression, and whether you have actually wired API tests into a CI pipeline rather than just clicking "Run" manually.
Strong answer covers: Newman runs headless on any Node.js environment, making it suitable for GitHub Actions, Azure DevOps, or GitLab CI. Mention that Newman outputs JUnit XML so results appear in pipeline dashboards. NZ signal: many NZ agencies running Azure DevOps (e.g. government, utilities) can drop a Newman step into an existing YAML pipeline in under an hour — it is often the fastest path to automated API regression for teams already using Postman.
You’re a QA engineer at a NZ fintech. Your Postman collection passes every request locally, but Newman fails three tests in the CI pipeline with “401 Unauthorized”. How do you diagnose this?
What they’re really testing: Whether you can methodically debug environment-specific failures rather than assuming the tests are broken — a common interview trap to distinguish disciplined testers from those who blame the tool.
Strong answer covers: First, check the Newman run command — is the correct --environment file being passed? Then verify the environment JSON is committed to the repo and contains the right variable names (not the actual secret values). Check whether the token in CI is expired or injected as a pipeline secret that maps to a different variable name than Postman expects. Mention that NZ Privacy Act obligations mean CI secrets must be injected at runtime, not stored in version control, so the environment file should reference a variable name that the pipeline populates.
How would you structure a Postman collection for an e-commerce API that has 80+ endpoints across orders, inventory, payments, and customers?
What they’re really testing: Whether you can design a maintainable test suite rather than a flat list of requests, and whether you understand how to chain data between requests using variables.
Strong answer covers: Organise by domain folder (Orders, Inventory, Payments, Customers) with sub-folders for happy path, error cases, and edge cases. Use pm.environment.set() in test scripts to capture IDs from create responses and pass them into subsequent requests (e.g. capture order_id from POST /orders, then use it in GET /orders/{{order_id}}). Add a collection-level pre-request script for shared auth. NZ signal: a SaaS company serving NZ retail would also want a folder for GST/tax edge cases specific to the NZ tax model.
What are the limitations of Postman for API testing, and when would you recommend replacing or supplementing it?
What they’re really testing: Whether you have a mature, honest view of the tool rather than treating Postman as the answer to every API problem — senior interviewers value people who know when not to use something.
Strong answer covers: Postman has weak support for WebSockets and SSE; tests live outside the codebase so they are not code-reviewed or refactorable in the same way; performance testing is superficial (use k6 instead); contract testing requires a separate tool like Pact. Supplement or replace with REST Assured when the team is Java-first and wants API tests in the same repo as the application. NZ signal: teams working under NZISM or ISO 27001 security frameworks often need full audit trails on test assets — a code-based framework committed to a git repo provides a clearer audit history than a shared Postman workspace.