How do you run Postman collections in CI with Newman or the Postman CLI?

Two runners

• Newman is the open-source command-line runner, installed from npm. It runs exported collection and environment JSON files.
• The Postman CLI is Postman’s own binary (postman collection run). It can run collections by UID straight from a workspace after postman login --with-api-key, and send results back to Postman.

Both run headless, return a non-zero exit code when any assertion fails, and work in any CI system. I tend to choose Newman when collections are kept in Git and reviewed like code, and the Postman CLI when the team works mainly in Postman workspaces.

Where the collection comes from

Options, in rough order of preference:

1. Exported JSON in the repo, so changes go through pull requests and the pipeline runs exactly the reviewed version.
2. Fetched via the Postman API by UID with an API key; always current, but changes skip code review.

Running with Newman

npx newman run collections/orders.postman_collection.json \
  -e environments/staging.postman_environment.json \
  --env-var "clientSecret=$CLIENT_SECRET" \
  --folder "Smoke" \
  --timeout-request 10000 \
  -r cli,junit \
  --reporter-junit-export results/newman-junit.xml

• -e loads the environment; --env-var overrides individual values, which is how secrets come in from the CI secret store.
• --folder runs a subset, for example a fast smoke folder on every PR and the full regression nightly.
• -d data.csv adds data-driven iterations.
• --bail stops on the first failure, useful for smoke gates.
• The junit reporter is built in; newman-reporter-htmlextra is a popular community HTML reporter installed separately.

GitHub Actions example

name: api-tests
on: [pull_request]
jobs:
  newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g newman
      - run: >
          newman run collections/orders.postman_collection.json
          -e environments/staging.postman_environment.json
          --env-var "clientSecret=${{ secrets.CLIENT_SECRET }}"
          -r cli,junit --reporter-junit-export results/newman.xml
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: newman-results
          path: results/

In Jenkins the same command runs in an sh step, and the junit 'results/*.xml' step publishes the results.

Making it reliable

• Secrets: never commit environment files with real tokens; keep only placeholders in Git.
• Data: generate unique data per run or clean up, so parallel pipelines do not collide.
• Environment readiness: wait for the service health endpoint before starting, otherwise the first requests fail for the wrong reason.
• Readable failures: descriptive pm.test names make the JUnit report useful without opening Postman.
• Scale: as a suite grows past a few hundred requests with complex logic, consider whether a code-based framework (REST Assured, Playwright API testing) would be easier to maintain and review. Postman collections are fine for smoke and contract-style checks but diffs of exported JSON are harder to review.

What interviewers look for

• Knowing Newman and the Postman CLI and the trade-offs of each.
• A concrete command with environment, secret injection and JUnit output.
• Exit-code-based gating and publishing reports in the pipeline.
• Practical concerns: secrets, test data, environment readiness, reviewability.