Postman Wants Your API Tests Running in the CI/CD Pipeline
Developers who still run their Postman collections by hand may be leaving their APIs dangerously exposed. Postman is now pushing a clear message: API tests in the CI/CD pipeline are no longer optional, they are the standard.
Unit tests run in CI. Integration tests run in CI. Yet the Postman collection, which often covers more realistic end-to-end behaviour than both combined, still runs only when someone opens the collection runner. That is the gap worth closing.
Until recently, getting a Postman collection into a pipeline was awkward. Teams had to either export a JSON file and commit it to the repo, an opaque blob no one wants to review in a pull request, or reference a collection by its workspace ID, meaning tests and code lived in completely separate places with no clear relationship between them.
That problem is now largely solved. The Postman CLI enables teams to run their test collections, monitors, flows, and more as part of a CI/CD pipeline, monitoring results every time there is a push to a code repository.
The key, however, is connecting a Postman workspace to a Git repository first via Native Git and team workspaces. Once that connection is in place, collections exist as files in the repo, no export step, no workspace ID to track. As Postman explains, the path passed to the CLI is simply a path in the repository.
For teams using GitHub Actions, wiring it all in is a small step. Check out the code, install the CLI, and run the collection against the chosen environment. Every push and every pull request triggers the collection. Failures surface before anything merges.
The other half of the equation is enforcing consequences when tests fail. If a pipeline runs the tests but still deploys on failure, teams have added noise without adding protection. Blocking on failure turns the test from a reporting tool into a genuine gatekeeper.
The case for this shift is straightforward. The manual test step is the weakest link in most API release processes, not because developers are careless, but because it depends on memory and time, and both run short under pressure. Automated tests don’t forget. They run on every change, surface failures before they reach users, and provide evidence that the API behaves correctly rather than an assumption.
For teams that want to go further, Postman now offers a dedicated Runs tab under each collection, showing all past collection runs from the Collection Runner or Postman CLI, along with counts of passed, failed, or skipped tests and average response times.
