Postman review 2026: plans, AI credits, and running collection tests in CI

Postman began as a simple way to send HTTP requests and has grown into a platform for designing, testing, documenting, monitoring and now automating APIs with AI. That growth is useful, but it also makes the product harder to evaluate: which parts does a developer or a small team actually need, what does the free plan cover, and when is it worth paying?

This review answers those questions using Postman's pricing page and its Learning Center documentation, both checked on 7 October 2026. We did not run performance benchmarks or a long-term team trial for this review; where we describe features, we describe what Postman documents. The code samples follow Postman's documented syntax for test scripts and the Postman CLI.

You will get an overview of the plans, a short hands-on section that adds tests to a collection and runs them in GitHub Actions, and a verdict on who should pay for which tier.

What Postman is today

At its core Postman is still an API client: you build requests, organise them into collections, use environments for variables such as base URLs and tokens, and inspect responses. Around that core, the pricing page lists:

• Specs and mock servers for designing an API before it exists.
• Native Git support, so collections can live alongside code.
• Collection Runner and Postman CLI for running test suites locally or in CI.
• Monitors for scheduled checks against live APIs.
• Flows for building API workflows visually.
• Postman AI, including Agent Mode, metered by AI credits.
• Documentation, a VS Code extension, an MCP client and SDK generation on higher tiers.

Most developers will use the client, collections, environments and tests every day; the rest matters once an API has several consumers or a team behind it.

Plans and prices (October 2026)

The pricing page says annual billing saves "up to 25%" compared with monthly billing. AI usage beyond the included credits is pay-as-you-go: $0.05 per credit on Solo, $0.04 on Team and $0.035 on Enterprise, with volume pricing available. Cloud performance testing is billed at $0.04 per virtual-user hour on paid plans, while local performance testing is listed as unlimited.

The key limit is the user count. Free and Solo each include one user. As soon as two people need to edit the same collections, the Team plan is the entry point.

Hands-on: add tests to a collection

Postman test scripts are JavaScript that runs after a response arrives. According to the Learning Center, they go in the Scripts > Post-response tab of a request, folder or collection, and the pm object exposes the response along with Chai's BDD assertion syntax. The following script checks a JSON endpoint that returns a list of products and stores the first ID for the next request.

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

pm.test("Response is JSON with a data array", function () {
    const body = pm.response.json();
    pm.expect(body).to.have.property("data");
    pm.expect(body.data).to.be.an("array").that.is.not.empty;
});

pm.test("Response time is under 800 ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(800);
});

// Pass the first product ID to the next request in the collection
const first = pm.response.json().data[0];
pm.collectionVariables.set("productId", first.id);

A following request can then use {{productId}} in its URL. Run the collection from the Collection Runner to see each test in the Test Results tab.

Hands-on: run the collection in GitHub Actions

The Postman CLI runs the same collection outside the app. Postman documents an official GitHub Action, postmanlabs/postman-cli-action@v1, that installs the CLI and runs a command. For a collection exported to the repository you do not need an API key; for collections stored in the Postman cloud you pass one from a repository secret.

name: api-tests

on:
  pull_request:
  push:
    branches: [main]

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

      # Option 1: collection and environment committed to the repository
      - name: Run Postman collection (local files)
        uses: postmanlabs/postman-cli-action@v1
        with:
          command: 'collection run tests/collection.json --environment tests/environment.json --bail'

      # Option 2: collection stored in Postman (uncomment and set the IDs)
      # - name: Run Postman collection (cloud)
      #   uses: postmanlabs/postman-cli-action@v1
      #   with:
      #     command: 'collection run 12345678-collection-id --environment 87654321-environment-id'
      #     api-key: ${{ secrets.POSTMAN_API_KEY }}

The --bail option, according to the CLI reference, stops the run on the first error. The CLI exits with a non-zero code when a failure is detected, so a failing assertion fails the job. On your own machine the documented install command for macOS and Linux is:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
postman collection run tests/collection.json --environment tests/environment.json

Two cautions. Keep real secrets out of committed environment files; inject them from CI secrets instead. And note the CLI documentation's warning that, when signed in, run results are uploaded to Postman, which you may or may not want for a given project.

Collections as code

A long-standing complaint about API clients is that requests live in a separate tool rather than in the repository. Postman's current answer is native Git support and a newer collection format. The CLI documentation describes how postman collection new scaffolds a "v3" collection on disk as a directory, with a definition file for the collection's settings and a separate file for each request. Collections in this format are YAML, so changes show up as readable diffs in a pull request.

This matters for review. When a developer changes an endpoint, the matching request and its tests can change in the same commit, and the CI job above runs them before merge. The same documentation notes a limitation worth knowing: for v3 YAML collections, only the cli report output is supported, so if your CI system expects JUnit XML from the run, test that combination before you migrate.

Postman also lists a VS Code extension on every plan, which lets developers send requests and run collections without leaving the editor. Teams that already work in VS Code may find this reduces the need to switch between applications.

Strengths

• Low barrier to entry. The free plan covers the client, collections, mock servers, native Git and the Collection Runner for one person.
• Tests travel with the collection. The same scripts run in the app, the CLI and CI, so manual exploration turns into automated checks without a rewrite.
• Breadth. Documentation, monitors, mocks and SDK generation sit in one tool, which helps small teams avoid stitching several services together.
• Clear AI metering. Each plan lists its AI credits and per-credit overage price.

Weaknesses and things to watch

• Collaboration starts at Team. Free and Solo are single-user plans, so a two-person team pays for two Team seats.
• Cloud by default. Signed-in runs upload results, and shared workspaces live in Postman's cloud. Organisations with strict data rules should read the security documentation and check the EU-only data residency option in Postman's plan comparison table.
• Feature sprawl. The number of products can be confusing for someone who only needs to send requests and run tests.
• Advanced security is an add-on. SSO and SAML are listed under a Simple Security add-on for Team, and advanced controls under an Advanced Security add-on for Enterprise.

Verdict: who should pay for what

Summary

Postman remains a strong default for working with HTTP APIs, and its free plan is enough for an individual developer. The paid tiers are reasonably priced for what they add, but the single-user limit on Free and Solo means any real team should budget for Team seats. Start by writing tests in the Post-response tab, run them in CI with the Postman CLI action, and decide on a paid plan only when sharing, documentation or monitoring needs justify it.