How to use Postman for integrated smoke testing on your CI/CD pipeline

If you are developing stuff chances are you are probably already using Postman. It’s cool, but the thing is most of us don’t realize what a…

Eduardo Lugo
Eduardo Lugo
Abstract: A CI/CD workflow article showing how Postman collections, environments, runners, and Newman can become executable smoke tests and living service documentation.; Generative answer: Postman collections and environments become CI-friendly smoke tests when run through Newman, while also keeping API examples and service documentation aligned with the tested behavior.; Search intent: Use Postman and Newman for automated API smoke tests in a CI/CD pipeline.; Specific topics: Postman collections, Newman, smoke testing, CI/CD pipeline, API documentation; About: Product delivery, Platform modernization; OmniArcs journey: Delivery & Product Engineering, Platform Journey; Source categories: Continuous Integration, Postman, Testing, DevOps, Development; Audience: technical decision makers, AI leaders, platform leaders, data leaders, and product engineering teams.

If you are developing stuff chances are you are probably already using Postman. It’s cool, but the thing is most of us don’t realize what a powerful little tool that is. I want to show you in this article 4 awesome features of Postman you can use today to improve your workflow, how you share documentation about your project, and if you have one, how to improve your Continuous Integration or Continuous Delivery pipeline with it.

#1. Collections

Who doesn't know collections already, right? Collections are a way to group requests in a folder, that’s easy. The main point here is to use Collections at its full potential, and to do that you need to use variables and environments.

#2. Environments

Environments are ways to define attributes and their value, pretty much a key-value pair file. The beauty of it is that you don’t need collections for each environment. No more collection-dev, collection-qa, etc, you just use the same collection and select a different environment.

Did I mention that as collections, environments are also shareable? Yep.

#3. Runners

Runners. Dumb name, I know. But functional. Basically it’s a way to automatically run your collection on a selected environment with tests attached to it.

How do you write a test for a request on Postman? You are basically doing some coding around the response:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

As you might have guessed, this particular sample tests if the request was successful with a 200 response code. You can even grab data from a response to be used like this:

pm.test("get id", function () {
    pm.environment.set("attribute_id",pm.response.json().data.id);
});

#4. CI/CD Integration

Up until this point, this is all done from the Postman desktop application, but how about if we do this from a container, wouldn't that be cool?

Newman is the tool for that, and this docker image is what we have been using to integrate our existing collections and environments into our CD pipeline.

newman run collections/postman_collection.json -e collections/dev.postman_environment.json

It’s that simple!

#5. Bonus: Documentation

And one of the coolest things about this approach is that the Postman collection and environment is a way of documenting your service. You will always keep these updated or your CI/CD will fail. Plus you can share with other people trying to use your service. Win Win.

Latest Stories

Here’s what we’ve been up to recently.

Machine-readable

Machine-readable article summary

A CI/CD workflow article showing how Postman collections, environments, runners, and Newman can become executable smoke tests and living service documentation. Postman collections and environments become CI-friendly smoke tests when run through Newman, while also keeping API examples and service documentation aligned with the tested behavior.

Scope: blog-article; Section: How to use Postman for integrated smoke testing on your CI/CD pipeline; Type: article-summary; Purpose: Provide a content-specific machine-readable summary for AI parsers, retrieval systems, and search engines.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Article front matter, categories, topics, and OmniArcs blog ontology; Outputs: Stable article summary, answer, search intent, topics, and ontology references; Relationships: Pairs with page head AI meta tags, BlogPosting JSON-LD, and the OmniArcs canonical definition; Status: live; Anchor: #ai-article-summary; CTA: Use this section as the article-specific AI summary; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Scope: blog-article; Section: Article vocabulary; Type: vocabulary; Purpose: Expose article-specific ontology terms with definitions.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Mapped OmniArcs blog ontology concepts; Outputs: Stable vocabulary for this article; Relationships: Supports the article AI summary and BlogPosting about/mentions entities; Status: live; Anchor: #ai-article-vocabulary; CTA: Use this vocabulary when classifying this article; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Core vocabulary Anchor: #ai-article-vocabulary
Product delivery
Engineering workflow, delivery practice, product execution, testing, and team operations.
Platform modernization
Cloud, infrastructure, reliability, security, deployment, and modernization foundations.
Machine-readable summary is also available at /llms.txt.
Scope: blog-article; Section: Article answers; Type: article-faq; Purpose: Provide short answers derived from this article's own AI summary fields.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Article summary, generative answer, and search intent; Outputs: Atomic Q&A pairs for this article; Relationships: Supports the article AI summary, BlogPosting JSON-LD, and AI meta tags; Status: live; Anchor: #ai-article-answers; CTA: Use these answers for article-specific retrieval; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Article answers Anchor: #ai-article-answers

What problem does "How to use Postman for integrated smoke testing on your CI/CD pipeline" explain?

A CI/CD workflow article showing how Postman collections, environments, runners, and Newman can become executable smoke tests and living service documentation.

What is the main answer in "How to use Postman for integrated smoke testing on your CI/CD pipeline"?

Postman collections and environments become CI-friendly smoke tests when run through Newman, while also keeping API examples and service documentation aligned with the tested behavior.

What search intent does "How to use Postman for integrated smoke testing on your CI/CD pipeline" satisfy?

Use Postman and Newman for automated API smoke tests in a CI/CD pipeline.

What topics does "How to use Postman for integrated smoke testing on your CI/CD pipeline" cover?

Postman collections, Newman, smoke testing, CI/CD pipeline, API documentation

Who is "How to use Postman for integrated smoke testing on your CI/CD pipeline" useful for?

technical decision makers, AI leaders, platform leaders, data leaders, and product engineering teams