Comparison

APIWeave compared with Postman Flows

Both put API work on a canvas. They are aimed at different jobs: Postman Flows builds and deploys API-first apps, and APIWeave builds API tests that run on your machine. This page sets out the differences plainly, and says what each tool is better at.

Postman statements verified September 22, 2026against Postman's documentation.

Download APIWeave Read the APIWeave source

Side by side

Twelve dimensions, no scoreboard

Neither column is a verdict. Read down the column that matches what you are trying to do.

Feature comparison between APIWeave and Postman Flows, verified against each product's documentation on September 22, 2026
Dimension	APIWeave	Postman Flows
What the canvas builds	An API test: HTTP request, assertion, delay, merge, and call-workflow nodes wired with pass/fail edges.	An API-first app: blocks that store data or perform a task, connected to automate and deploy workflows.
Where it runs	Your machine. The desktop app sends the requests and evaluates the assertions locally.	Local canvas or Postman cloud. Deployed flows run as public URLs; a Cloud Run toggle tests on the local canvas in the cloud environment.
Account requirement	None for the desktop app. A Cloud account is optional and adds collaboration on structure only.	Postman account. Flows are built in workspaces and deployed flows run on Postman's cloud.
Assertions	A dedicated Assertion node with source, path, operator, and expected value, and separate pass and fail edges through the graph.	Tests written with the pm API in an Evaluate block, which outputs structured test results on a Tests port.
Reusing a response value	JSONPath extractors write workflow variables; the prev namespace reads the upstream response directly.	Select extracts a field, Evaluate and If run FQL or TypeScript, and Create/Get Variable blocks move the value on.
Logic language	No scripting language in a node. Logic is assertion rules, merge strategies, and placeholders; a coding agent can drive the graph over MCP.	Flows Query Language (FQL) or TypeScript, with TypeScript able to define tests through the pm API.
Version control	Workflows live in a local SQLite database and can be exported as a bundle; each machine keeps its own secret store.	Cloud View syncs automatically. Local View stores flows as JSON in a Git repo, but Local View flows cannot be shared or deployed and do not support snapshots.
Running flows inside flows	A Call Workflow node runs another workflow inline as one step, with input and output variable mappings.	A Flow block references another flow that has at least one snapshot.
Cloud execution and scheduling	None. Cloud never builds, runs, or hosts workflow execution, and there is no scheduler.	Deploy a flow to a public URL, or trigger it on a schedule. A deployed flow's timeout is set between 5 and 30 seconds.
Exposing the tool to AI agents	An opt-in loopback MCP bridge on 127.0.0.1 hands a local agent a whitelist of tools to author, diagnose, and run workflows.	Flows can be deployed as MCP servers on Postman's cloud, and Agent Mode builds or extends flows in natural language.
Secret handling	Secret values are sealed in a write-only local store; workflows reference {{secrets.NAME}} and Cloud carries only the reference.	Vault secrets are stored in Postman and used from the desktop app or through an agent; variables and environments hold the rest.
Cost model	Free and open source under MIT. No metering of runs or blocks.	Flows consume credits per block based on where it runs, with a monthly allocation per plan and an optional pay-as-you-go overage.

The same job

One token, one fan-out, two canvases

Both tools can do this. The difference is in what each node is.

APIWeave

The assertion is its own node, so a failing contract routes the run down a visible branch.

Chained API test

[ Start ] -> [ POST /login ] -> [ Assertion: status == 200 ]
                              |
                   extractor: token = response.body.access_token
                              |
          +-> [ GET /orders   Authorization: Bearer {{variables.token}} ]
          +-> [ GET /profile  Authorization: Bearer {{variables.token}} ]
                              |
                    [ Merge: all ] -> [ End ]

Postman Flows

The request is an HTTP Request block bound to a collection request; extraction and tests happen in the blocks around it.

Blocks on a flow canvas

[ Start ] -> [ HTTP Request: POST /login ] -> [ Select: body.token ]
                                                          |
              +-> [ HTTP Request: GET /orders  (token port) ]
              +-> [ HTTP Request: GET /profile (token port) ]

Tests are written in an Evaluate block with the pm API, which sends
results out of a Tests port.

Which one

Pick the tool that matches the job

These are the cases where each one is clearly the better fit — including the ones where that is not APIWeave.

Choose APIWeave when

You want the tests to run on your machine, against your own environments, with no service in the request path.
You want an assertion to be a first-class node with its own pass and fail branches, rather than a script inside a data-transformation block.
You want to open the tool, build a workflow, and run it without creating an account.
You would rather read and audit the whole thing: the desktop app and this control plane are both public under MIT.

Choose Postman Flows when

You want to deploy the workflow itself as a public HTTP endpoint, or run it on a schedule.
You are already deep in Postman collections, environments, and the Postman API Network.
You want a full programming language inside a step, with tests written against the pm API.
You want cloud-hosted MCP servers as a first-class feature rather than a local bridge.

Two things neither tool hides

APIWeave does not run your tests in the cloud. That is a deliberate boundary, not a gap to be filled: Cloud stores no run history and no response payloads, and it rejects a sync payload carrying secret material. If you need a workflow to be reachable at a public URL, that is Postman Flows' job.
Postman Flows is not a free local runner. Flows consume credits per block depending on where the block runs, each plan has a monthly allocation that does not roll over, and runs pause at the limit unless pay-as-you-go is on. A manual local-canvas run consumes credits only for blocks that execute in the cloud, unless Cloud Run is enabled.

Provenance

Where every Postman statement came from

Read the primary sources rather than trusting this page. Documentation changes, so re-check anything decisive.

The APIWeave column restates this project's own documentation and the product boundary recorded in CLAUDE.md. This page has no affiliation with Postman, and no claim is made about which tool is better in general — only about which one fits which job.