Postman CLI vs Newman: Running Postman Collections in CI in 2026

The Postman CLI and Newman both run Postman collections from the command line and fail the CI job when a test fails. As of October 2026, Postman recommends the Postman CLI, which runs v3 YAML collections, lints API specifications, and uploads results to Postman when signed in. Newman is open source, needs no account, keeps results local, and is not deprecated, but it only runs v2.1 JSON collections. For a collection that must live in git and never touch a vendor cloud, Bruno’s bru run is the third option.

I have had this conversation on three bank programmes now. The QA lead wants the Postman collection in the pipeline, the platform team asks which runner, someone pastes a two-year-old blog post, and security asks the only question that matters: where do the results go? This article answers it with current commands, verified against Postman’s documentation and the Newman repository in October 2026. It sits in the advanced track of APIs for Analysts and picks up where running API tests in CI left off.

What are the Postman CLI and Newman, and who maintains them?

Both are maintained by Postman. They solve the same core problem, running a collection headlessly with a non-zero exit code on failure, from different starting points.

	Newman	Postman CLI
Maintainer	Postman (postmanlabs/newman on GitHub)	Postman
Licence	Open source	Closed source, signed binary
Install	npm install -g newman	Install script or npm install -g postman-cli
Account needed	No	No for local files; yes for cloud collections, result upload, and governance
Collection formats	v2.1 JSON only	v2.1 JSON and v3 YAML (Native Git)
Where results go	Terminal and local report files	Terminal and local reports; uploaded to Postman when signed in and run by ID
Beyond collections	Nothing	Monitors, mocks, spec linting, workspace commands
Latest version (9 Oct 2026)	6.2.3	1.71.0

Current status, verified. Postman’s documentation page on migrating from Newman calls the Postman CLI “the recommended command-line tool for running collections” and states that Newman “isn’t compatible with capabilities introduced in Postman v12, including Native Git workflows and the collection v3 format.” On 29 September 2026 a change to the Newman README described Newman as being in maintenance mode. Eight days later the maintainers reverted that wording, writing in the commit that it “reads as deprecation, which was not the intent” and that “Newman is not deprecated and not unmaintained.” Release 6.2.3, published 9 October 2026, carries a README pointing to the Postman CLI as the more powerful option.

So the honest summary: Newman works, is maintained, and gets few feature releases (the last one with a new feature was 6.2.0 in August 2024; since then a revert, a dependency update, and the README change). New Postman capabilities land in the Postman CLI only.

How do you install and run the Postman CLI?

Install it with the official script or with npm:

# macOS, Linux, WSL
curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

# any platform with Node.js
npm install -g postman-cli

Sign in with an API key. This is the method Postman recommends for CI, because nothing opens a browser:

postman login --with-api-key "$POSTMAN_API_KEY"

# Enterprise EU Data Residency plan
postman login --with-api-key "$POSTMAN_API_KEY" --region eu

The CLI also reads the POSTMAN_API_KEY environment variable directly, and every command accepts --api-key. Then run a collection by its ID from a workspace, or by a path on disk:

# collection in a Postman workspace, by ID
postman collection run 12345678-aaaa-bbbb-cccc-1234567890ab \
  -e 12345678-dddd-eeee-ffff-1234567890ab

# collection exported to the repository
postman collection run api-tests/payments.postman_collection.json \
  -e api-tests/sit.postman_environment.json \
  --env-var "clientSecret=$SIT_CLIENT_SECRET" \
  -i "10-smoke" \
  --bail \
  -r cli,junit \
  --reporter-junit-export results/junit.xml

The options an analyst actually uses in a pipeline:

Postman CLI option	What it does	Newman equivalent
-e <file or ID>	Environment	-e <file>
--env-var name=value	Inject a secret at runtime	--env-var name=value
-d <file>	Iteration data (CSV or JSON)	-d <file>
-i <folder or request>	Run one folder or request, repeatable	--folder <name>
--bail	Stop on first failure	--bail
-r cli,json,junit,html	Reporters	-r cli,json,junit (HTML is an external reporter)
--reporter-junit-export <path>	JUnit file location	Same flag
--timeout-request <ms>	Per-request timeout	Same flag
--report-events=false	Stop reporting to API Catalog	Not applicable

One trap worth knowing before you design the gate. Postman’s reporter documentation says all built-in reporters work for v2 JSON collections, but “only the CLI reporter is available for HTTP, gRPC, and GraphQL collections in v3 format (YAML).” If your pipeline publishes a JUnit file to the test results tab and the team migrates to Native Git, check the reporter docs again before the migration, because the JUnit file may stop appearing.

How do you run a collection with Newman?

Newman is one npm package and one command. With the collection and environment exported to the repository:

npm install -g newman

newman run api-tests/payments.postman_collection.json \
  -e api-tests/sit.postman_environment.json \
  --env-var "clientSecret=$SIT_CLIENT_SECRET" \
  --folder "10-smoke" \
  --bail \
  -r cli,junit \
  --reporter-junit-export results/junit.xml

Newman 6 requires Node.js 16 or later. Its built-in reporters are the CLI, JSON, and JUnit ones; an HTML report needs an external reporter package installed alongside it, such as the community newman-reporter-htmlextra. Newman never asks for a Postman account, and when it runs files from your repository it sends nothing to Postman’s cloud, which is the property that has kept it in bank pipelines for a decade.

Newman’s limitation is the input format. It reads v2.1 JSON. If the collection lives in a Postman workspace, someone has to export it to the repository, and if nobody owns that export, the pipeline tests last month’s suite. Bruno vs Postman for analysts covers why that export step is the weak point in most Postman-based pipelines.

What does API governance linting add?

This is a Postman CLI feature with no Newman equivalent, and it is the one that changes an analyst’s job. postman spec lint checks an OpenAPI specification for syntax errors and against your team’s governance rules:

postman spec lint openapi.yaml --fail-severity ERROR
postman spec lint openapi.yaml --fail-severity WARNING -o JSON

--fail-severity sets the threshold that fails the build (HINT, INFO, WARNING, ERROR; the default is ERROR), and -o switches the output to JSON or CSV for a report. Governance checks require signing in, and the rules come from your Postman team’s governance configuration (a local file is checked against the “All workspaces” group by default, or a specific workspace with --workspace-id). The check is only as useful as the rules your API platform team configured, so ask to see them.

Why it matters to an analyst: a spec that fails linting on missing error responses, missing examples, or inconsistent naming is a contract defect found before a single test runs. It is the automated version of the checks in an API design review. If your organisation does not use Postman governance, the open-source Spectral linter covers the same ground without an account.

Where do the results go, and why does a bank care?

This is the question security will ask, so answer it in writing before the first run.

Newman: results go to the terminal and to the report files you name. Nothing is sent to Postman.

Postman CLI: Postman’s documentation says that “when you’re signed in, the CLI uploads run results to Postman, from local runs and CI.” That covers collections run by ID, and Git-native collections run by path when they are linked to a cloud collection. A run from a local file that is not linked to Postman “runs, but its results aren’t uploaded and the CLI prints a message saying so.” Separately, run results are reported to the API Catalog and Application Inventory by default; --report-events=false (or --no-report-events) turns that off.

Uploaded results include each test’s assertion names, pass or fail status, and error details. In a payments suite, error details and assertion names often quote the values that failed: an IBAN from test data, an amount, an EndToEndId. Even if the data is synthetic, many bank data policies classify test data shaped like production as confidential, and a cloud upload is a data transfer that needs approval.

What I put in the test strategy for a Postman CLI pipeline:

1. Which collections run by ID or linked path (results uploaded) and which run from unlinked files (results local). Read the CLI’s own message on the first run to confirm.
2. Whether --report-events=false is set, and why.
3. The Postman region (--region eu on an EU Data Residency plan, which Postman offers to Enterprise customers with data hosted in Frankfurt).
4. That uploaded artifacts exclude secrets: the JSON and HTML reporters accept options such as --reporter-html-omitHeaders, so authorization headers stay out of files anyone with repository access can download.
5. Who owns the Postman API key used by CI, and when it rotates.

What does the GitHub Actions YAML look like for each?

Postman CLI with the official action. The action installs the CLI and signs in with the key:

name: api-tests
on:
  pull_request:
    paths: ["openapi.yaml", "api-tests/**"]

permissions:
  contents: read

jobs:
  postman-cli:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Lint the contract
        uses: postmanlabs/postman-cli-action@v1
        with:
          command: "spec lint openapi.yaml --fail-severity ERROR"
          api-key: ${{ secrets.POSTMAN_API_KEY }}

      - name: Run smoke folder
        uses: postmanlabs/postman-cli-action@v1
        with:
          command: >-
            collection run api-tests/payments.postman_collection.json
            -e api-tests/sit.postman_environment.json
            -i 10-smoke
            -r cli,junit
            --reporter-junit-export results/junit.xml
            --report-events=false
          api-key: ${{ secrets.POSTMAN_API_KEY }}

      - uses: actions/upload-artifact@v7
        if: ${{ !cancelled() }}
        with:
          name: postman-results
          path: results/

Newman, no account.

jobs:
  newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: "24"
      - run: npm install -g newman@6
      - name: Run smoke folder
        run: |
          mkdir -p results
          newman run api-tests/payments.postman_collection.json \
            -e api-tests/sit.postman_environment.json \
            --folder "10-smoke" \
            --env-var "clientSecret=${{ secrets.SIT_CLIENT_SECRET }}" \
            -r cli,junit \
            --reporter-junit-export results/junit.xml
      - uses: actions/upload-artifact@v7
        if: ${{ !cancelled() }}
        with:
          name: newman-results
          path: results/

For a test environment inside the corporate network, both jobs need a self-hosted runner, exactly as in running API tests in CI. Pin versions (newman@6, or the action’s postman-cli-version input) so a runner upgrade does not change your gate overnight.

If your suite also validates events, the same runner choice applies: automating Kafka validation in Postman runs that suite with either tool. The test design that makes any of these gates worth having, with the banking cases behind it, is in API Testing and QA Mastery for BAs, and the scripting side of the pipeline is in The BA Automation Guide.

Where does the Bruno CLI fit?

Bruno is the git-native third option. Collections are plain text files in the repository (OpenCollection YAML by default since Bruno v3.1, or the older .bru format), the CLI needs no account, and nothing is synced to a vendor. The current CLI is @usebruno/cli 4.2.1:

npm install -g @usebruno/cli

bru run 10-smoke -r \
  --env sit \
  --env-var clientSecret="$SIT_CLIENT_SECRET" \
  --bail \
  --reporter-junit results/junit.xml \
  --reporter-html results/report.html

Bruno’s CLI runs scripts in a safe sandbox by default since v3; --sandbox=developer is only needed when scripts load npm packages or the filesystem. If you are moving off Postman, Bruno imports Postman collections, so the migration cost is mostly re-checking scripts that use Postman-specific APIs. When I generate collections with an assistant, Bruno’s files are also the easiest output to review, which is the argument in AI-built API collections and scripts.

Which one should you choose?

Your situation	Choose	Why
Team works in Postman workspaces and wants results in Postman	Postman CLI	Runs by ID, no export step, results visible to the team
Team adopted Postman v12 Native Git or v3 YAML collections	Postman CLI	Newman cannot read v3
You want the contract linted against governance rules in the pipeline	Postman CLI	postman spec lint with --fail-severity
Exported v2.1 JSON in the repo, results must never leave the network	Newman	No account, no upload, JUnit built in
Existing Newman pipeline that works, no v12 features needed	Newman, for now	Not deprecated; plan the move when you adopt v3
Collection must be reviewed as files in pull requests, no vendor cloud	Bruno CLI	Plain text in git, no account, local only
Security review is the bottleneck in a bank	Bruno CLI or Newman	Easiest data-flow story to approve

My default on a new banking programme: Bruno if the team has a free choice, the Postman CLI with --report-events=false and file-based runs if the organisation is standardised on Postman, and Newman only to keep an existing pipeline alive until the team migrates.

What do analysts get wrong when they switch runners?

• Assuming the commands are identical. Most flags carry over, but --folder becomes -i, and HTML reports change from an external Newman package to a built-in Postman CLI reporter.
• Forgetting the data flow. Moving from Newman to the Postman CLI can quietly start uploading results. Write down whether it does.
• Breaking the JUnit gate on v3. Migrating collections to v3 YAML before checking reporter support removes the file your CI test tab reads.
• Personal API keys in CI. Use a key owned by a service account or team, stored as a secret, with a rotation date.
• Never seeing the gate fail. After the switch, break one assertion on purpose, rerun the negative cases from your API test cases, and confirm the job goes red. A runner that exits 0 on failure is worse than no runner. The practice exercise in the Analyze a Payment API lab is a good place to rehearse what a failing assertion should catch.

The takeaway

The Postman CLI is Postman’s recommended runner and the only one that runs v3 YAML collections, lints specs against governance rules, and reports back to Postman. Newman is open source, account-free, local-only, and not deprecated, but limited to v2.1 JSON collections and without Postman v12 features such as Native Git. Bruno’s bru run is the option when collections belong in git and nothing may leave the network. Pick by where the collection lives and where results are allowed to go, write the data flow into the test strategy, pin the runner version, and prove the gate fails before you trust it.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: API Testing, Postman, Newman, Bruno, CI/CD