Postman Collection Runner Restrictions: What Changed and How to Work Around It

TL;DR

Postman restricted Collection Runner access on its free tier, breaking automated test execution for teams that haven’t upgraded. This affects local test runs, CI/CD pipelines, and any workflow that used Runner for bulk request execution. This article explains what changed, what it breaks in practice, and how Apidog’s runner works without restrictions on any plan.

Try Apidog today

Introduction

Postman’s Collection Runner used to be a default part of many API testing workflows. You could build a collection of requests, click Run Collection, execute them in sequence, pass variables between requests, run assertions, and review a summary report.

That made it useful for practical developer workflows like:

• Smoke testing before deployment
• Running API regression tests in CI
• Testing multi-step authentication flows
• Replaying the same collection with different data
• Running basic iteration-based performance checks

With the 2026 free tier restrictions, Postman limited Collection Runner access. Free accounts can no longer run collections beyond a monthly usage limit, and some Runner-related features are now paywalled.

The impact is immediate if your team relies on automated batch execution instead of sending individual requests manually.

What Postman changed in Collection Runner

Postman’s free tier now restricts Collection Runner in three main areas.

1. Monthly run limits

Free accounts now have a cap on how many Collection Runner executions they can perform per month. Postman has not clearly published the exact number, but community reports place it around 25 runs per month.

For developers running test collections several times per day, that limit can be reached quickly.

2. Newman CLI restrictions

Newman is Postman’s CLI runner for executing collections in local terminals and CI/CD pipelines.

Previously, teams could export a Postman collection and run it with Newman without worrying about account-level limits:

newman run collection.json -e environment.json

After the 2026 changes, some Newman workflows are affected when using cloud-synced collections or account-connected features tied to a Postman plan.

3. Visual Runner restrictions

The visual Collection Runner in the Postman app can show a paywalled or throttled state after the free account run limit is reached.

Manual single-request execution still works. You can still click Send on one request. The restrictions mainly affect automated batch execution.

What breaks in practice

Pre-commit and pre-deployment smoke tests

A common workflow is to run a smoke test collection before merging a PR or deploying to staging.

Example:

• 30 requests in a smoke test collection
• 3 developers
• Each developer runs it twice per day

That results in 6 collection runs per day. If the free limit is around 25 runs per month, the team can exhaust it in less than a week.

CI/CD pipelines

Newman-based CI pipelines are affected when they depend on Postman collection execution.

A typical GitHub Actions workflow might look like this:

- name: Run API tests
  run: newman run ./collections/api-tests.json -e ./environments/staging.json

Once the account limit is reached, CI jobs may fail or hit usage-related errors. This is especially disruptive when pipelines trigger on every push or pull request.

End-to-end API workflows

Many teams use Postman collections to model multi-step API flows:

1. Log in
2. Extract an auth token
3. Store the token in an environment variable
4. Use the token in follow-up requests
5. Assert each response

In Postman, this often uses pm.environment.set():

const json = pm.response.json();
pm.environment.set("access_token", json.token);

With Runner restricted, these flows can no longer be executed as a full automated sequence on the free tier after the limit is reached. Developers must either run requests manually or use another runner.

Load and performance-style checks

Postman Collection Runner supports options like delay and iterations. Teams often use this for lightweight stress testing or repeated validation.

For example:

• Run the same collection 100 times
• Add a delay between requests
• Check whether key endpoints remain stable

With run limits, this workflow is no longer practical on the free tier.

Immediate workarounds within Postman

If you are not ready to switch tools, there are a few short-term workarounds.

Export collections and run Newman locally

You can export your collection and environment files, then run Newman against local JSON files:

newman run collection.json -e environment.json

This avoids depending on a cloud-synced collection.

The tradeoff: you lose automatic sync with your active Postman workspace. Every collection update requires a new export.

Split large collections

You can split a large collection into smaller collections.

For example:

api-tests.json
├── auth-tests.json
├── user-tests.json
├── billing-tests.json
└── admin-tests.json

This may reduce friction in some cases, but it is not a clean solution. It can break request chaining and make end-to-end flows harder to maintain.

Upgrade only the account used for CI

If the main blocker is CI, one option is to upgrade only the account used by the pipeline.

That paid account can run automated workflows, while other developers continue using manual testing on free accounts.

This can reduce cost, but it does not solve the broader issue for teams that need every developer to run test suites locally.

How Apidog’s Collection Runner works differently

Apidog’s runner is available through Test Scenarios or the Run button on a collection. It has no monthly run limits on any plan, including the free tier.

Here is the practical comparison:

Feature	Postman free	Apidog free
Runner executions/month	~25 reported	Unlimited
CI/CD runs with CLI	Limited	Unlimited
Iterations per run	Limited	Unlimited
Request chaining with variables	Limited	Unlimited
Test assertions	Available	Available
Run summary report	Available	Available

Apidog’s CLI runner, apidog-cli, can be used in CI/CD similarly to Newman.

Example command:

apidog run {project-id} --collection {collection-id} --environment {env-id}

You can also export a collection from Apidog and run it offline, similar to the local Newman workflow, without relying on account-based run limits.

Setting up Apidog runner in a CI pipeline

If you currently run Newman in GitHub Actions, the migration is mostly a CLI and authentication change.

Before: Newman

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

- name: Run API tests
  run: newman run ./collections/api-tests.json -e ./environments/staging.json --reporters cli,json --reporter-json-export results.json

After: Apidog CLI

- name: Install Apidog CLI
  run: npm install -g apidog-cli

- name: Run API tests
  run: apidog run --project {project-id} --env {env-id} --output results.json
  env:
    APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

The main differences are:

• Apidog uses an access token
• The command references an Apidog project/environment
• Test output can still be exported as JSON for reports

Store the token as a GitHub Actions secret:

APIDOG_ACCESS_TOKEN

Then reference it in your workflow:

env:
  APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Alternative: keep Newman and export from Apidog

If your team wants to keep using Newman temporarily, you can export an Apidog collection as a Postman-compatible JSON file and run Newman against it:

newman run ./collections/api-tests.json -e ./environments/staging.json

This lets you:

• Manage APIs in Apidog
• Export collections when needed
• Keep existing Newman-based CI scripts during migration
• Avoid relying on Postman Collection Runner limits

This is useful if you want a gradual migration instead of changing all pipelines at once.

Advanced runner features in Apidog

Apidog’s runner covers common Collection Runner workflows and adds several practical testing options.

Data-driven testing

You can import CSV or JSON data and run the same test scenario with multiple data sets.

Example CSV:

email,password,expectedStatus
[e-mail],password123,200
[e-mail],wrongpassword,401

Each row can be used as one iteration of the test run.

Custom iteration counts

You can configure repeated execution without worrying about a monthly run counter.

Example use cases:

• Run a login flow 100 times
• Repeat a checkout scenario with different inputs
• Run basic stability checks against staging

Variable-based request chaining

Apidog supports chained workflows where data from one response is reused in another request.

Typical flow:

1. Send login request
2. Extract token
3. Save token as a variable
4. Use token in authorization headers
5. Continue the scenario

This is useful for testing real API flows instead of isolated endpoints.

Smart Mock integration

Apidog’s runner can work with Apidog’s built-in mock server.

That means you can test client behavior against mocked endpoints before the backend is fully implemented. This is useful for frontend teams, SDK development, and contract-first API workflows.

Scheduled runs

You can schedule test runs directly in Apidog, such as hourly or daily checks.

This helps with:

• Monitoring staging APIs
• Running recurring regression checks
• Keeping test history inside the API project

Summary

Postman’s Collection Runner restrictions create a practical blocker for teams that rely on automated API testing on the free tier.

The most affected workflows are:

• CI/CD test execution
• Pre-deployment smoke tests
• Multi-step API workflows
• Iteration-based testing
• Local batch execution by developers

Short-term workarounds include exporting collections, running Newman locally, splitting collections, or upgrading only the CI account.

For teams that need unrestricted runner execution, Apidog’s runner provides the same core workflow without monthly run limits. Its CLI can be added to existing pipelines with a small configuration change, and teams can also export Postman-compatible collections if they want to keep Newman during migration.