Newman

Visit Website

Introduction

Newman is a command-line collection runner for Postman. It takes a Postman collection, either exported as JSON or fetched by URL through the Postman API, and runs every request in order, executing the pre-request and test scripts written in the Postman app. It was built, in the README’s words, ‘with extensibility in mind’ so it can plug into continuous integration servers and build systems.

For many teams, Newman is how Postman tests become a CI gate. A developer or tester builds a collection in Postman with pm.test assertions, exports it with an environment file, and the pipeline runs newman run on every merge. If any assertion fails, Newman exits with a non-zero code and the build fails.

Newman supports environments and globals, iteration data from CSV or JSON files for data-driven runs, a configurable number of iterations, delays between requests, timeouts, SSL client certificates and proxies. Reporters control the output: built-in CLI, JSON, JUnit and progress reporters, plus community reporters such as HTML reports. It can also be used as a Node.js library to run collections programmatically.

Postman now also promotes the Postman CLI, a separate proprietary tool that integrates with the Postman cloud, and the Newman README points to it (‘Do more with the Postman CLI’). Newman remains open source, works offline with exported collections and still receives commits (most recently October 2026), which is why it remains common in pipelines that do not want a cloud dependency.

Newman has about 7,300 GitHub stars and is installed from npm, so it needs Node.js. A Docker image is also available.

In the quality loop, Newman sits at the API and integration stages and in release gates. It is the natural choice for teams that already author tests in Postman and need them to run headlessly.

The source code is at postmanlabs/newman on GitHub under the Apache-2.0 licence, with about 7,300 stars; the most recent commit was on 9 October 2026.

In practice, the value of Newman depends on the quality of the Postman collections behind it. Collections that contain real assertions in their test scripts, use environment variables instead of hard-coded hosts, and avoid order-dependent requests run well in CI; collections built purely for manual exploration usually need tidying first. Teams should also decide where the source of truth lives: exported JSON files committed to the repository give reviewable diffs, while pulling collections from the Postman API keeps them in sync with the workspace but adds a dependency on credentials. Newer Postman CLI tooling overlaps with Newman, so check which fits your licence and workflow.

Features

1. Runs Postman collections: Executes requests, pre-request scripts and pm.test assertions.
2. Environments and globals: Swap configuration per stage.
3. Data-driven iterations: CSV or JSON data files with -d.
4. Reporters: CLI, JSON, JUnit and progress built in; HTML via community reporters.
5. CI friendly: Non-zero exit code on failures.
6. Library mode: Run collections from Node.js code.
7. Network options: Proxies, client certificates, timeouts and delays.
8. Collection by URL: Run collections fetched from the Postman API.
9. Docker image: Run without installing Node.js locally.
10. Offline use: Works with exported JSON, no cloud required.

Pros

1. Reuses Postman work: No rewrite to get tests into CI.
2. Familiar: Huge Postman user base and examples.
3. Free to use: Open source under the Apache-2.0 licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 9 October 2026.
5. Community: About 7,300 GitHub stars.

Cons

1. Tests live in Postman format: Collections are JSON, harder to review than code or text.
2. Postman CLI overlap: Postman’s newer CLI gets new features; Newman may lag.
3. Node.js dependency: Needs Node.js or Docker in CI.

Usage and Links (Example)

Install and run a collection with an environment and JUnit output:

npm install -g newman
newman run collection.json -e staging.postman_environment.json \
  -d users.csv --reporters cli,junit --reporter-junit-export results/newman.xml

A Postman test script inside the collection:

pm.test("status is 200", () => pm.response.to.have.status(200));
pm.test("returns user", () => pm.expect(pm.response.json().email).to.eql("user@example.com"));

Practical tips:

1. Keep exported collections and environments in Git so changes are reviewed.
2. Store secrets as CI variables and pass them with --env-var instead of saving them in environment files.
3. Publish JUnit output so failing requests show in your CI test report.

Resources:

• Newman website

Pricing

Newman is free and open source under the Apache-2.0 licence.

Recommended for?

1. Teams already writing tests in Postman.
2. Pipelines that need offline, open-source collection runs.
3. Not a fit if you prefer API tests as code or text from the start.

Conclusion

Newman is the simplest way to turn Postman collections into automated CI checks. It is mature, widely used and still maintained.

Teams heavily invested in Postman’s cloud may prefer the Postman CLI, but Newman remains a solid, open choice for running exported collections anywhere.

On CheckOps, Newman is filed under the API & contract testing, Integration testing and Release & CI gates stages. Related tools listed here include Postman, Bruno, Hurl, Insomnia, Karate and PactumJS. Before choosing, compare them on licence, supported languages and platforms, hosting model, and how well each fits your existing CI pipeline. Facts on this page were checked against the official website, documentation and repository on 11 November 2026; statements the vendor makes about its own product are marked as vendor claims.