🧪 $200 Community Challenge – Run a Collection with the Postman CLI | 48 Hours

The weekly community challenge is live.
One winner gets a $200 Visa gift card.

This week is straightforward: run a Collection using the Postman CLI, then show how you’d run the same command in a CI pipeline.

The challenge

This is a two-step challenge.

Step 1: Run a Collection with the Postman CLI

Use the Postman CLI to run any Collection from a terminal.

You can:

  • Run your existing suite of tests
  • Use a Collection you actually care about rather than one just created for the challenge
  • Make use of the different CLI flags e.g -environment or --e in the Postman CLI command
  • Explore using the various built-in reporters to export the run results

If the CLI runs your Collection successfully, you’ve completed Step 1.

Step 2: Show how you’d run it in a CI/CD pipeline

Take the same CLI command or use a pre-built pipeline workflow template and show how you’d run it in CI

Examples CI/CD usage:

How to enter

Reply to this thread with:

  • What Collection you ran
  • The Postman CLI command you used
  • How you’d run it in CI (config snippet, screenshot, or short explanation)
  • One thing this setup gives you that running locally doesn’t
  • Any suggestions that would improve the Postman CLI

We’re looking for real workflows and real outcomes.

Prize and timing

  • Prize: $200 Visa Gift Card
  • Runs: Wednesday Feb 11, 2026 to Friday Feb 13, 2026
  • Deadline: Friday at 10:00am BST / 2:30pm IST

This contest is open worldwide to participants 18+. By entering, you grant Postman the right to feature your submission on our website, blog, and social channels.

1 Like

Hi Danny and Postman Team :waving_hand:
I completed both steps of the challenge successfully.
:white_check_mark: :one: What Collection I Ran
I ran my collection named:
“Get Post Test Collection”
It includes a GET request to:
Copy code

https://jsonplaceholder.typicode.com/posts/1

:white_check_mark: :two: Postman CLI Command Used
I used the following command in my terminal:
Copy code
Bash
postman collection run 46633248-3a334666-8f2f-439a-8b62-6f7f37bda87f
The collection executed successfully with status 200 OK.
:white_check_mark: :three: How I Ran It in CI (GitHub Actions)
I created a GitHub Actions workflow file:
Copy code

.github/workflows/postman-test.yml
Here is the workflow configuration I used:
Copy code
Yaml
name: Postman CLI Test

on:
push:
branches:

  • main

jobs:
test:
runs-on: ubuntu-latest

steps:
  - name: Checkout repository
    uses: actions/checkout@v3

  - name: Install Postman CLI
    run: |
      curl -o- "https://dl-cli.pstmn.io/install/linux64.sh" | sh

  - name: Run Postman Collection
    run: |
      postman collection run 46633248-3a334666-8f2f-439a-8b62-6f7f37bda87f
    env:
      POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}

The workflow ran successfully and showed a green checkmark :white_check_mark: in GitHub Actions.
:white_check_mark: :four: One Advantage of Running in CI
Running the Postman CLI in CI helps catch bugs early by automatically running API tests on every code push.
It ensures consistent validation and prevents broken APIs from reaching production.
:light_bulb: Suggestion for Postman CLI
It would be great to have a built-in option to generate clean HTML test reports directly from the CLI without requiring additional configuration.
GitHub profile used for this submission:
Shivampal157
Thank you for organizing this challenge! :rocket:

Hey @navigation-observe12 :waving_hand:

Welcome to the Postman Community! :postman:

Thank you for your submission! I noticed that the workflow file you shared is slightly different from the one currently running in the GitHub project.

Because it’s using a Postman API key and a Collection ID, it would usually need to authenticate first so it can retrieve the collection data before running successfully. You might just want to double-check that step is included.

The Postman CLI comes with a bunch of built-in reporters, including a HTML reporter, that can be included in the CLI command (-r html) and is created after the run.

Were you able to inspect the Collection Run in the Postman UI via the via shared at the end of the Github Action run?

Connecting your Workspace using the new Native Git feature in Postman, will allow you to automatically kick off the Collection run in the GH Action, when code is pushed to the project. This will give you an early indication of any test failures caused by the new changes.

Hi Danny :waving_hand:

Thank you again for pointing that out.I’ve now updated my GitHub Actions workflow to explicitly include the authentication step using:postman login --with-api-keybefore running the collection.

The workflow now:

Installs the Postman CLI

Authenticates using the API key stored in GitHub SecretsRuns the collection using the Collection IDGenerates reports using -r cli,htmlI verified the updated workflow and confirmed it runs successfully in GitHub Actions.Thank you for the guidance — I really appreciate the feedback! :rocket:

GitHub: Shivampal157

As something related to this particular challenge, I started a discussion on the Postman sub reddit to get a feel for the general usage of Newman vs Postman CLI:

It would be great to get your thoughts on this topic :heart:

1 Like

Greetings.

I am Llakterian and here is my response to the challenge.

What Collection You Ran

QuitVaping Production API Tests - A production API test suite for a quit vaping mobile application. This collection tests health check endpoints, user progress tracking, and craving logging functionality.


The Postman CLI Command You Used

# Step 1: Fetch collection from Postman API with authentication
curl -X GET "https://api.getpostman.com/collections/$COLLECTION_ID" \
  -H "X-Api-Key: $POSTMAN_API_KEY" \
  -o postman/fetched-collection.json

# Step 2: Run with built-in reporters
npx newman run postman/fetched-collection.json \
  -e postman/fetched-environment.json \
  -r cli,html,junit,json \
  --reporter-html-export results/newman-report.html \
  --reporter-junit-export results/newman-results.xml \
  --reporter-json-export results/newman-results.json \
  --bail

Key Features:

  • Uses Postman API authentication to fetch latest collection
  • Built-in reporters (no external plugins required)
  • Stops on first failure (--bail) for CI environments
  • Multiple output formats (HTML, JUnit XML, JSON)

How You Would Run It In CI

GitHub Actions Configuration:

name: Postman API Integration

on:
  push:
    branches: [ main ]
  schedule:
    - cron: '0 9 * * 1'  # Weekly on Monday at 9AM

env:
  POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}
  COLLECTION_ID: ${{ secrets.POSTMAN_COLLECTION_ID }}
  ENVIRONMENT_ID: ${{ secrets.POSTMAN_ENVIRONMENT_ID }}

jobs:
  postman-api-run:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Install Newman
      run: npm install -g newman

    - name: Fetch Collection from Postman API
      run: |
        curl -X GET "https://api.getpostman.com/collections/${COLLECTION_ID}" \
          -H "X-Api-Key: ${POSTMAN_API_KEY}" \
          -o postman/fetched-collection.json

    - name: Fetch Environment from Postman API
      run: |
        curl -X GET "https://api.getpostman.com/environments/${ENVIRONMENT_ID}" \
          -H "X-Api-Key: ${POSTMAN_API_KEY}" \
          -o postman/fetched-environment.json

    - name: Run with Built-in Reporters
      run: |
        newman run postman/fetched-collection.json \
          -e postman/fetched-environment.json \
          -r cli,html,junit,json \
          --reporter-html-export results/newman-report.html \
          --reporter-junit-export results/newman-results.xml \
          --bail

    - name: View Collection Run in Postman
      run: |
        echo "View results: https://go.postman.co/reports/collection-run/${COLLECTION_ID}"

Screenshot/Explanation:
The workflow runs automatically on:

  1. Every push to main branch
  2. Every pull request
  3. Weekly on Monday at 9AM (scheduled)

Results can be viewed in GitHub Actions tab and at: https://go.postman.co/reports/collection-run/{COLLECTION_ID}


One Thing This Setup Gives You That Running Locally Does NOT

Automated Scheduling + Centralized Management + History

Running in CI provides capabilities that local runs cannot match:

  1. Scheduled Runs: Tests run automatically every Monday at 9AM without manual intervention
  2. Secure Authentication: API keys stored as encrypted GitHub secrets, never exposed in code
  3. Centralized Collection Management: Fetches the latest collection directly from Postman API
  4. Historical Tracking: All runs saved in Postman Reports for comparison and trend analysis
  5. Failure Alerts: Immediate detection and notification when tests fail
  6. Artifact Preservation: HTML and JUnit reports saved for 90 days in GitHub
  7. Branch Protection: Can prevent merges when critical tests fail

Suggestions That Would Improve the Postman CLI

1. Built-in OAuth Support

Currently, OAuth authentication requires manual token retrieval. Native support would simplify CI usage:

newman run collection.json --oauth-token-url "https://auth.example.com" \
  --oauth-client-id "$CLIENT_ID" --oauth-client-secret "$CLIENT_SECRET"

2. Native GitHub Action

A dedicated GitHub Action would eliminate the need for curl commands:

- name: Run Postman Collection
  uses: postman/newman-action@v1
  with:
    collection-id: ${{ secrets.POSTMAN_COLLECTION_ID }}
    environment-id: ${{ secrets.POSTMAN_ENVIRONMENT_ID }}
    reporters: cli,html,junit

3. Parallel Test Execution

Built-in support for running collections in parallel would improve CI execution time:

newman run collection.json --parallel 4

4. Better WebSocket Support

WebSocket-based collections currently have limited CLI support.


Additional Notes

  • GitHub repository: llakterian/QuitVaping
  • Workflow files located in .github/workflows/
  • Postman workspace linked for collection management
  • Native Git integration available via Postman Branches feature

Hi Danny,

Please review the steps below.:

Collection Name: SDET_API

I ran a sample Grocery Store API, which includes:

Test Cases:

  • VerifyStatus
  • SaveProducts
  • GetProductDetails
  • CreateACart
  • AddProductToCart
  • UpdateProductToCart
  • GetCart
  • CreateToken
  • CreateAnOrder
  • GetOrderDetails
  • UpdateOrder

The collection is stored as SDET_API.postman_collection.json and uses a SDET_API_QA.postman_environment.json

Commands:

postman login --with-api-key PMAK-

postman collection run SDET_API.postman_collection.json --environment SDET_API_QA.postman_environment.json -r json,html --reporter-json-omitHeaders --reporter-json-omitResponseBodies

How would I run it in CI:

  • Checkout code from repository
  • Install Node.js
  • Install Postman CLI
  • Login using API_KEY secret
  • Run Postman collection with environment, generate JSON/HTML reports
  • Copy HTML report as index.html for Pages
  • Upload reports as downloadable artifacts
  • Configure GitHub Pages
  • Upload reports to Pages
  • Deploy to GitHub Pages
  • Display report URL in workflow summary
name: Postman API Tests

on:
  push:
    branches: [ main, master ]
  pull_request:
    branches: [ main, master ]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  api-tests:
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout repository
      uses: actions/checkout@v4
      
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'
        
    - name: Install Postman CLI
      run: |
        curl -o- "https://dl-cli.pstmn.io/install/linux64.sh" | sh
        
    - name: Login to Postman CLI
      run: postman login --with-api-key ${{ secrets.API_KEY }}
        
    - name: Run Postman Collection
      run: postman collection run SDET_API.postman_collection.json --environment SDET_API_QA.postman_environment.json -r json,html --reporter-json-omitHeaders --reporter-json-omitResponseBodies || true
        
    - name: Prepare HTML Report for GitHub Pages
      if: always()
      run: |
        cd postman-cli-reports
        cp $(ls *.html | head -n 1) index.html
        
    - name: Upload Test Reports
      if: always()
      uses: actions/upload-artifact@v4
      with:
        name: postman-test-reports
        path: postman-cli-reports/
        
    - name: Setup Pages
      if: always()
      uses: actions/configure-pages@v4
      
    - name: Upload artifact to Pages
      if: always()
      uses: actions/upload-pages-artifact@v3
      with:
        path: postman-cli-reports/
        
    - name: Deploy to GitHub Pages
      if: always()
      id: deployment
      uses: actions/deploy-pages@v4
      
    - name: Add Report URL to Summary
      if: always()
      run: |
        echo "## Test Report Published! 📊" >> $GITHUB_STEP_SUMMARY
        echo "View the HTML report at: ${{ steps.deployment.outputs.page_url }}" >> $GITHUB_STEP_SUMMARY

Running the CLI inside CI gives:

  • Automatic runs on each push
  • No dependency on local machine configuration
  • Ability to stop merges on failing API tests
  • The test report available at GitHub Pages

My favourite part is the inbuilt reporting, which produces clean HTML reports
and it working super on both locally and in GitHub Actions without using Newman

Suggestion:

Add customization options for the HTML reporter, ability to add a company logo.

Thank you for hosting this challenge. I really enjoyed the task :slight_smile:

CI/CD usage: GitHub Actions

What Collection you ran : I ran my SkillMatch API Test Collection, which validates a Spring Boot application I built for resume-to-job-role matching.
The collection tests the /api/resume/extract-skills endpoint by sending a resume file and verifying that the service correctly parses and returns detected technical skills.

This is part of an actual workflow used to validate backend changes before deployment.

The Postman CLI command you used: postman collection run --env-var baseUrl=http://localhost:8080, where I used an environment variable (baseUrl) so the same collection can run locally or inside CI without modifying requests. Attached SS for reference.

How you’d run it in CI: I integrated this into GitHub Actions so the API is validated automatically on every push.

One thing this setup gives you that running locally doesn’t: It validates the API in a clean, reproducible environment every time.

  1. APIs are tested automatically on every push not dependent on someone remembering to run them locally.
  2. The same Postman collection runs in a clean environment every time, eliminating “works on my machine” issues.
  3. API tests become part of the delivery pipeline instead of a manual step.

Any suggestions that would improve the Postman CLI: A health-check or wait mechanism maybe which can make CI usage smoother by removing the need for manual sleep steps while services start.

Good Day Note:- This year addition of new challenges like these feels great.

Postman CLI + CI/CD - API Reliability Intelligence Pipeline

Problem

API checks are often run manually in Postman before release, which makes results inconsistent, easy to skip and not enforced at merge time. My goal was to convert API testing from a manual step into a repeatable CI quality gate.

What I Built

I used my “API Reliability Intelligence” Postman collection and executed it using the Postman CLI, then integrated it into a GitHub Actions CI pipeline so every push automatically validates API behavior before changes are accepted.

This reflects how production teams prevent regressions in critical API flows.

Collection — Real Reliability Scenario

My collection validates real API reliability signals:

  • Multi-request workflow validation
  • Response status and schema assertions
  • Data integrity checks
  • Failure detection using test scripts
  • Structured pass/fail reporting
  • Reusable environment configuration

Each request includes automated tests, not just request execution, so failures are detected programmatically.

Run via Postman CLI (Local Reproducible Run)

Postman-generated CLI command used:

postman collection run <collection-id> --postman-api-key=$POSTMAN_API_KEY

Result:

  • Full collection executed locally
  • Assertions evaluated automatically
  • Run report generated
  • Results synced to Postman cloud

This makes execution deterministic and reproducible across machines and team members.


CI/CD Integration - GitHub Actions Pipeline

I connected the same collection to GitHub Actions using the official Postman CLI Action.

Workflow behavior:

  • Triggers on every push and pull request
  • Installs Postman CLI automatically
  • Authenticates using a secure repository secret
  • Runs the collection in CI
  • Fails the pipeline if any test fails

CI workflow snippet:

name: Postman CLI Run

on:
  push:
  pull_request:

jobs:
  run-postman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: postmanlabs/postman-cli-action@v1
        with:
          api-key: ${{ secrets.POSTMAN_API_KEY }}
          command: >
            postman collection run api-reliability.json

DevOps Maturity Practices Applied

  • API key stored in GitHub Secrets (not hard-coded)
  • Collection exported and version-controlled
  • CLI command generated directly from Postman Runner
  • CI run logs visible for audit and debugging
  • Pipeline path error diagnosed and corrected during setup
  • Same collection runs locally and in CI (environment parity)

Why CI Execution Beats Local Runs

Local runs prove correctness once.
CI runs prove correctness continuously — every commit, every contributor, every branch — and automatically block merges when tests fail. This turns API tests into an enforced reliability gate instead of a manual checklist.


Outcome

This setup upgrades a Postman collection from a manual testing artifact into a CI-enforced API reliability guardrail:

  • One command to reproduce locally
  • Automatic execution in CI
  • Secure secret handling
  • Deterministic validation
  • Merge blocking on failures

Real workflow. Real automation. Production mindset.

Based on leaning about Postman CLI on the discord channel. For this challenge I converted to postman cli from newman for all pipelines(dev, test, prod).

Step 1: Run a Collection with the Postman CLI

Step 2: Show how you’d run it in a CI/CD pipeline

I have existing postman jobs running in a pipeline on Azure Devops. I use CI Template where I pass multiple collections and Environments to be executed on a scheduled basis.

In one file I swapped out my existing Newman installs with Postman CLI. I also changed my “newman run” with "postman collection run”. I did have to ask AI about permissions. Change NPM commands made me have to do some extra permissions.

Here is my git changes to my pipelines.

Here are the results of one of the pipelines which matches local.

Example Postman job executing Postman Collection on Server.

A automated pipeline gives you automation. Running locally doesn’t.

Having automated daily checks allows me to check multiple environments to make sure dependent APIs in all environments are responding correctly. I also use my daily checks to understand SLA with third party vendor’s api’s.

Any suggestions that would improve the Postman CLI.
I would like the ability to pass in a collection of collections to run instead of having to run each as a single line. Example: postman collection run {col1, col2, col3) -e (env1, env2, ev4).

1 Like

What Collection You Ran: CacheCraft Behavior Suite
Purpose: Verifies cache CRUD operations and metrics reporting for a local Spring Boot app with Redis.

Tests included:

  • Add cache entry

  • Retrieve cache entry

  • Check cache stats

  • Clear cache

Postman CLI Command: postman collection run $POSTMAN_COLLECTION_UID
–env-var baseUrl=http://localhost:8080
–env-var metricsUrl=http://localhost:8081
–bail
–reporters cli,json
–reporter-json-export cache-report.json

**How You’d Run It in a CI/CD Pipeline:

Trigger:** On every push or pull request in GitHub.

  1. Setup: Start Redis service and build Spring Boot app.

  2. Run App: Launch CacheCraft locally in the pipeline.

  3. Run Postman CLI: Use the official Postman CLI GitHub Action with API key and collection UID:

postman collection run $POSTMAN_COLLECTION_UID \
  --env-var baseUrl=http://localhost:8080 \
  --env-var metricsUrl=http://localhost:8081 \
  --bail \
  --reporters cli,json \
  --reporter-json-export cache-report.json

  1. Collect Results: Upload the JSON report as a pipeline artifact.

One Thing This Setup Gives You That Running Locally Doesn’t: reproducible runs

  • Every push or PR triggers the pipeline

  • Test results are automatically captured (cache-report.json)

  • No dependency on your local machine being up or configured

Suggestions to Improve Postman CLI:

  1. Better error messages when environment or collection is missing.
  2. Include a built-in retry mechanism for flaky network or service endpoints.
  3. Optional HTML + JSON combined reporters for easier review in CI dashboards.

I ran a custom Nimbus Billing API Validation collection that covers a full SaaS billing flow:

The collection is environment-aware and runs against a real local backend

Postman CLI command used

postman collection run 47444924-58f303b4-cfcc-4ec8-924f-1c9199b93323 \
  -e 47444924-8df8dffd-8f04-4048-b622-dfff49824fa6 \
  --env-var baseUrl=https://155a5c81-f51c-4f56-86f3-fd3cb068e2ee.mock.pstmn.io \
  --reporters cli,json,junit

For local development, I switch the base URL:
–env-var baseUrl=``http://localhost:3000

How I run this in CI

I run the collection on every push using GitHub Actions and the official Postman CLI action.
High-level flow:

  • GitHub Actions checks out the repo
  • Authenticates with Postman using an API key
  • Runs the collection against a private mock server
  • Fails the build if any assertion fails
  • Uploads JSON/JUnit reports as artifacts

Example step:

- name: Run Postman Collection
  uses: postmanlabs/postman-cli-action@v1
  with:
    command: >
      collection run 47444924-58f303b4-cfcc-4ec8-924f-1c9199b93323
      -e 47444924-8df8dffd-8f04-4048-b622-dfff49824fa6
      --env-var baseUrl=https://155a5c81-f51c-4f56-86f3-fd3cb068e2ee.mock.pstmn.io
      --reporters cli,json,junit
  env:
    POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}

One thing this setup gives me that running locally doesn’t

Locally, everything depends on data being present (IDs, transitions, order of calls).
In CI, the mock server + Postman CLI lets me:

  • validate contracts
  • verify error handling (404, 409, invalid transitions)
  • catch breaking changes early

I can refactor the backend and know immediately if I broke the api contract without spinning up a database or seeding data.

Suggestions to improve the Postman CLI

  • Better first-class support for environment flags (e.g. mock vs real) without manual branching in tests
  • Clearer output grouping for passed vs skipped assertions
  • A built-in way to mark assertions as “expected in mock mode” vs “expected in real mode”

Overall though, the CLI was stable and reliable enough to build a real CI workflow around it.