POC — Running Postman Flows in CI Without Paying for Enterprise

We had a perfectly organised Postman collection, a clean CI pipeline, and a desire to run multi-step API flows automatically on every pull request. But we hit a wall. The only thing standing between us and that goal was a paywall.

Here’s how we got around it — without duplicating a single request.

The Problem: We Wanted Flows, Not Just Folders

Our backend exposes a REST API. We use Postman to document and test every endpoint. After a while, individual endpoint tests started feeling hollow — they told us each request worked, not whether the API held together as a system.

What we really needed to validate was sequences. The kind of journey a real client goes through:

• Admin logs in
• Creates an organisation
• Edits it
• Views it to confirm the change persisted
• Sends an invitation request

Or a more complex one involving two users — an admin who creates an organisation and sends an invitation, and a member who logs in separately and accepts it. Each step depends on the one before. When the user logs in, the access token must persist to be used on the other API calls to keep authentication.

These aren’t just endpoint tests. They’re user journeys expressed as API calls.

Postman has a feature built for exactly this: **Flows**. It’s a visual canvas, distinct from the Collections view, where you drag saved requests onto a board, connect them with arrows, and define the sequence without writing orchestration code. Variables pipe automatically between steps.

The Postman Flows canvas showing the Organisation creation flow. Request nodes are connected by arrows. Variable bindings are visible between steps.

We started building flows there. They were clear, maintainable, and made it immediately obvious how the API was meant to be used.

Then we tried to run them in CI.

The Limitation: Postman Flows Require Enterprise to Run from CLI

Postman has a CLI tool that includes a postman flows run command. We got excited. We read the docs. Then we hit this:

postman flows run requires a Postman Enterprise plan.

We’re a small team. Enterprise pricing for a test runner felt like a lot.

We tried Newman, Postman’s open-source CLI runner. It takes a collection JSON file and an optional environment file, fires every request in sequence, and reports the results. Free, no account required. But it does not support running flows and possibly never will. There is a GitHub issue requesting Newman support for Flows with plenty of 👍 reactions and no resolution.

Using folders in Postman

Newman can organise requests into folders and run a specific folder with --folder. The obvious approach: create a folder per flow, put the requests in order, and run each folder. Sounds right, right?

There are two problems.

First, there’s no sequencing across folders. If your flow needs requests from different folders — a login from Requests/Authentication/, then Organisation/Invite member- you can't compose them without copying. There's no concept of "run this request from over there, then this one from here."

Second, that duplication compounds fast. Our collection had duplicate “Invite member” requests — one under Organisation, one under Flows. Every time the endpoint changed, we'd have to update multiple places.

Both copies of “Invite member” visible side by side under different parent folders — the duplication problem in plain sight

Postman Flows solve this elegantly on the canvas — you drag the same request block into multiple flows without duplicating anything. In a Collection, there’s no concept of a reference or alias.

The POC

The idea is to have placeholder requests inside the Flows folder. They perform no actual HTTP call and serve only as documentation for the flow sequence.

The flow definitions

The flow definition is a tiny JSON file listing step names in order. A Node.js script does the assembly. See dev/Postman/flows/org-creation.json

{
  "name": "Organisation creation",
  "description": "Admin logs in, creates an organisation, edits it, and views it.",
  "steps": [
    "Organisation admin login",
    "Create Organisation",
    "Edit Organisation",
    "View Organisation"
  ]
}

The runner script

The script run-flow.js takes two inputs that already exist in any Postman project:

• The collection JSON — exported from Postman desktop (File → Export → Collection v2.1). This contains every request definition, test script, and variable.
• The environment JSON — also exported from Postman. It holds the base URL, credentials, and any environment-specific values.

The script reads both, looks up the named requests, assembles a temporary collection, and hands it to Newman.

The repository layout

project-root/
├── mock-server.js                               ← demo mock API (npm run mock)
├── test.js                                      ← starts mock, runs all flows, stops mock (npm test)
└── dev/
    └── Postman/
        ├── collection/
        │   └── my-api.postman_collection.json   ← exported from Postman
        ├── environments/
        │   ├── environment.mock.postman_environment.json   ← used by npm test (demo)
        │   ├── environment.local.postman_environment.json  ← your local API
        │   └── environment.ci.postman_environment.json     ← CI / staging
        ├── flows/
        │   ├── org-creation.json
        │   └── member-invitation.json
        └── run-flow.js

Sample output

Output of run-flow script

Running the Flows using a mock server

Check out the POC repo on this branch https://github.com/marcelovani/newman-flows/tree/medium-post-1, then run:

npm install
npm test

npm test starts the mock server, runs every flow against it, and stops it afterwards. No real API, no credentials, no network required.

To run a single flow against the mock server:

# Terminal 1 — start the mock server
npm run mock

# Terminal 2 — run one flow
ENV=mock node dev/Postman/run-flow.js "Organisation creation"
ENV=mock node dev/Postman/run-flow.js "Member invitation"

Pointing at your real API

When adapting this for your own project, replace the mock with your real backend. Export your Postman collection and environment files into the same folder structure, then run:

# Against a local dev server (uses environment.local.postman_environment.json)
node dev/Postman/run-flow.js "Organisation creation"

# Against a staging or CI server (uses environment.ci.postman_environment.json)
ENV=ci node dev/Postman/run-flow.js "Organisation creation"

The environment files contain the base_url and credentials for each target. For CI, set ADMIN_USERNAME, ADMIN_PASSWORD, MEMBER_USERNAME, and MEMBER_PASSWORD as environment variables (or GitHub Actions secrets).

CI Integration

In GitHub Actions, the flows run automatically on every push and pull request:

- name: Run Newman — all flows
  run: npm test

- name: Store Newman artifacts
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: newman-results
    path: tests/results/newman
    retention-days: 7

Adding a new flow requires no changes to run-flow.js or the CI workflow. Drop a new.json file into dev/Postman/flows/ and it's automatically picked up on the next run.

What We Gained

• No duplication. Every request is defined exactly once. Flows are just ordered lists of names.
• Free plan only. No Enterprise subscription, no cloud execution, no Newman patches.
• Postman Flows canvas still works for design. We kept using it to diagram and document — just not to run.
• CI-friendly. JUnit XML and HTML reports are generated per flow and uploaded as artifacts.
• Self-discoverable. Drop a new .json intodev/Postman/flows/ - no other changes needed.

Limitations

This approach is a workaround, not a first-class solution.

Step names must match exactly. If someone renames a request in the Postman desktop and exports the collection without updating the flow JSON, the runner exits with a helpful error. It’s a light coupling, but it’s there.

Parallel branches aren’t supported. Postman Flows can run request blocks in parallel on the visual canvas. Our sequential runner can’t. Every flow is a straight line — which covers the vast majority of API test scenarios.

The Takeaway

To be blunt: this workaround is not as good as Postman Flows.

Flows give you a visual canvas where sequences are immediately legible — you can see what connects to what, where variables flow between steps, and how branches fork. Our JSON files and a Node.js script are a pale imitation of that.

If your team is already on Enterprise, use postman flows run - it's the right tool.

But if you’re on the free plan and need multi-step API flows in CI without duplicating request definitions, the underlying problem is solvable with the tools you already have. A small Node.js script and a handful of JSON files gets you most of the way there.

If Postman ever ships Newman support for Flows on the free plan, delete run-flow.js and don't look back.

The full implementation referenced in this post is at https://github.com/marcelovani/newman-flows/tree/medium-post-1

Spoiler: While I was writing this article, things evolved quickly, so a new post will be required to talk about https://www.npmjs.com/package/newman-flows