Anypoint runs your APIs. Postman is where everyone else works.

I worked at MuleSoft before joining Postman, and I used both products the whole time I was there. Postman has always been the default way to test an API, including for the people building them on Anypoint.

The question comes up in almost every conversation I have with a MuleSoft team: we already pay for Anypoint Platform, why would we add another API tool?

It is a reasonable question. The short answer is that Postman is not a second Anypoint, and it is not a client with tests bolted onto it. It is a platform for the API lifecycle: spec design with real change control, mocking, contract and performance testing, governance as code, cataloguing, distribution. It covers stages Anypoint was not designed for, and serves roles Anypoint was never built for.

MuleSoft implements APIs in low-code and secures them behind the Omni Gateway. That is not the subject of this post, and it is not what Postman replaces.

Two things change when you run them side by side. Who can participate in your APIs, and how quickly you can change those APIs without loosening your standards.

Who can reach your APIs today

Anypoint is built for the people who implement integrations, and those are the people who log into it. A QA engineer or a product manager has no reason to open Design Center or API Manager, because nothing in there is addressed to them.

Everyone else still touches those APIs, though. The front-end and mobile teams. QA. The product managers who need to know whether an endpoint is ready. Data engineers calling a service from a notebook. The external partner integrating with you. That group is usually several times larger than the Mule team.

So the work moves into email and Slack, and the real cost is the churn. There is no single place that is current. An API changes, and someone has to rebuild the collection by hand to match it. What gets shared is a copy, so the front-end team ends up testing against a collection exported three weeks ago, reporting a bug that was fixed a fortnight back, and the integration team spends an afternoon proving the endpoint was fine all along. Multiply that by every API and every consuming team and it becomes a permanent tax on both sides.

Salesforce owns MuleSoft and still chose Postman’s Public API Network for external distribution: its workspace is among the most active publishers there, with more than 200,000 collection forks, and it hosts MuleSoft’s own Anypoint Platform APIs collection. MuleSoft’s blog has also described Postman as the standard for any developer working with APIs. The company that owns Anypoint reached a similar conclusion about the consumer side of the lifecycle.

Who owns which stage

Stage by stage, click through it:

MuleSoft owns the middle. Postman covers the edges, and the connective tissue that makes changing the middle less risky.

Collaboration, concretely

You import your deployed API definitions from Anypoint Exchange into Postman and keep them in sync. Exchange stays the runtime source of truth. But a QA engineer, a product manager or a partner can now find that API, read it, try it, fork it into their own workspace and write a test against it. Same APIs, same runtime, usable by the rest of the company.

Three things matter in practice:

Partner Workspaces. Isolated spaces where external developers work alongside your team on shared collections, without platform access being handed out or a collection export circulating by email. Exchange and Experience Hub give consumers a portal to read; this is somewhere to co-develop.

One catalogue rather than three. Exchange lists what went through Mule. Your developers also consume internal APIs that were never Mule-ified, plus Stripe, plus whatever the data team stood up on its own. Postman’s API Catalog discovers from any source and shows spec version, governance score, CI history, test outcomes and an owner per API. Exchange shows spec status. Those answer different questions, and only one of them tells you whether a service is safe to depend on right now.

A single front door. Publishing the API to the Private API Network gives everyone one search box, and the entry in it stays tied to the spec rather than to somebody’s export. Teams tend to describe this need before anyone suggests it, because Anypoint was never meant to serve a product manager or a QA engineer, and Postman was.

Designing the contract with real change control

Design Center authors RAML and OpenAPI perfectly well. Three properties make it awkward as a collaborative design surface, and they are structural rather than cosmetic:

• No concurrent editing. One person holds the spec and everyone else waits.
• Auto-commit on every change. You end up with thousands of commits carrying no intent. The history exists but nothing can be read from it, so versioning stops being useful and becomes noise.
• No quality gate before Exchange. Governance exists, but anything can be published. A design policy violation tends to surface at test time, after the API is deployed, and only if that check was set up.

Postman Specs are Git-native, which addresses all three: branch a spec, open a pull request, review it, gate the merge with RBAC. Governance rules run inline in the editor while you type, then again in CI before the merge. Anypoint has no equivalent review-and-approve workflow for a spec change, and that remains true in an organisation fully committed to MuleSoft.

There is a second reason to author in Spec Hub, and it is the one that matters most day to day. The spec and the collection are the same artefact, so generating the collection from the spec, and regenerating it when the spec changes, is one click. That is the churn from earlier in this post disappearing: nobody exports a collection, nobody sends it round, and nobody tests against a copy that stopped being accurate three weeks ago.

The flow I would set up looks like this. The spec is authored in Spec Hub rather than hand-edited in a repository:

      ┌──────────────────────────────────────────────────┐
      │ Spec Hub                                         │
      │ authoring, inline governance rules               │
      └────────────────────────┬─────────────────────────┘
                               │  local mode
                               ▼
      ┌──────────────────────────────────────────────────┐
      │ Git branch + pull request                        │
      │ review, RBAC on the merge                        │
      └────────────────────────┬─────────────────────────┘
                               │  CI
                               ▼
      ┌──────────────────────────────────────────────────┐
      │ postman spec lint                                │
      │ governance gate, blocks the merge                │
      └────────────────────────┬─────────────────────────┘
                               │  on merge
               ┌───────────────┴───────────────┐
               ▼                               ▼
  ┌──────────────────────────┐    ┌──────────────────────────┐
  │ Postman cloud            │    │ Anypoint Exchange        │
  │ collection, mock, tests, │    │ APIkit dependency,       │
  │ docs, API Catalog        │    │ runtime source of truth  │
  └──────────────────────────┘    └──────────────────────────┘

Local mode keeps the spec as real files in your repository, so Git handles transport and review while Spec Hub stays where humans and agents actually edit it. The merge fans out to both platforms, since you do need the API in Exchange for APIkit and Studio to resolve it.

Quicker and safer at the same time

Speed and safety usually trade against each other. The review board that catches breaking changes is also what slows every release down. That trade-off exists mainly because the gate is a person reading a diff.

Once the gates are codified, the relationship changes:

Wired into an Anypoint pipeline, the deploy itself is unchanged:

- name: Gate 1 - governance on the spec
  run: |
    postman login --with-api-key "$POSTMAN_API_KEY"
    postman spec lint ./specs/customer-360.yaml \
      --fail-severity ERROR \
      --report-events

- name: Sync the contract to Postman and to Exchange
  run: |
    postman workspace push --yes
    mvn deploy -Dexchange

- name: Deploy to CloudHub 2.0
  run: mvn deploy -DmuleDeploy -Denv=uat

- name: Gate 3 - contract tests against UAT
  run: |
    postman collection run "$COLLECTION_UID" \
      --environment "$UAT_ENVIRONMENT_UID" \
      --bail \
      --reporters cli,junit \
      --reporter-junit-export results.xml

- name: Promote to production
  if: success()
  run: mvn deploy -DmuleDeploy -Denv=prod

--report-events is a small flag that changes how this is perceived internally: lint results go back to Postman and appear per API in the API Catalog, under CI pipeline runs. Governance becomes a number attached to each service, visible to people who have no CI login, instead of a report someone produces once a quarter.

--bail matters too, so a broken contract stops the promotion rather than producing a red report nobody opens.

Why API tests should not live in the Mule project

MUnit covers the inside of a Mule application: DataWeave transforms, error branches, connector behaviour with mock-when. That is what it is for, and it is the right place for that kind of check.

It is a poor place to put your API testing, for reasons that are all about managing it rather than about what it can assert. It is written by hand, in the IDE, by someone who writes DataWeave, which rules out your QA engineers. It sits inside the API project, so there is no view of coverage across an estate. It runs against an implementation that has to exist first, so nothing can be tested before the flow is built. And changing a test means changing the application and redeploying it: the test lifecycle is welded to the deployment lifecycle, which is the opposite of what you want from a test.

It also does not follow the contract. Publishing a spec change to Exchange is one click and the mock regenerates itself, but the suite does not. Someone has to bump the spec version in the IDE and rewrite the tests by hand, so they drift away from the spec by default.

Tests generated from the spec in Postman invert all of that. They live next to the contract and regenerate with it. They run from a laptop, from CI, or on a schedule as a monitor, with no redeployment involved. And any role can read and extend them, which is what makes coverage somebody’s job rather than nobody’s.

Agent Mode is what makes this practical across an estate rather than on one API. Point it at a spec and it writes the functional and contract tests for every operation, including the error responses people skip. Point it at an endpoint whose contract just changed and it updates the affected assertions, rather than you hunting through a collection to find them. Ask it where coverage is thin and it will tell you, which is a question nobody can answer about MUnit suites spread across forty Mule projects.

Two related gaps:

• No field-by-field contract test. APIkit validates inbound traffic against the spec at runtime, and an MUnit suite can be generated from a spec, but nothing compares a live response to the published OpenAPI field by field and type by type.
• No native performance testing. The answer is JMeter, Gatling or BlazeMeter: a separate tool, a separate authoring environment, another thing to maintain.

These are the assertions running in the playground further down, against the Experience API response:

const body = pm.response.json();

pm.test("Status code is 200", () => pm.response.to.have.status(200));

pm.test("customerId matches the path parameter", () => {
  pm.expect(body.customerId).to.eql(pm.variables.get("customerId"));
});

// SAP names its fields in capitals (KUNNR, NAME1, KLIMK). The System APIs expose
// them as they are; the Experience API is meant to translate them. So any all-caps
// key in this payload means one of them slipped through, whichever one it is.
pm.test("No raw ERP field name leaks through", () => {
  const shouty = JSON.stringify(body).match(/"[A-Z][A-Z0-9_]{2,}":/g) || [];
  pm.expect(shouty, `leaked: ${shouty.join(", ")}`).to.be.empty;
});

pm.test("Available credit never exceeds the limit", () => {
  pm.expect(body.credit.available).to.be.at.most(body.credit.limit);
});

The third assertion is worth explaining, because it is the one specific to API-led. SAP names its fields in capitals: KUNNR for the customer number, KLIMK for the credit limit. The System API exposes them exactly like that, which is correct at that layer. The Experience API is supposed to translate them into business vocabulary, customerId and credit.limit. So the test does not look for one particular field. It scans the whole payload for any key written in capitals and fails if it finds one, whatever it happens to be called.

That catches a regression no MUnit suite will. Someone adds a field to the DataWeave mapping, forgets to rename it, and KLIMK is now in the public payload. The flow works, the transform is correct, and MUnit stays green, because nobody ever wrote an assertion saying that no field may be named in capitals. The contract is broken anyway: consumers are now reading SAP vocabulary that was supposed to stay behind the System API layer, and taking it away later is a breaking change.

Scheduling the same collection as a monitor keeps asserting all of this in production afterwards. One artefact from design through to production, nothing rewritten along the way, and nothing redeployed to change a test.

Mocking: a contract you can call before it exists

The Anypoint mocking service does something comparable from a spec, with one catch: it lives inside the Design Center project, and the caller needs a platform login. It is not a URL you hand to a partner.

Below is a fictional retailer running textbook API-led connectivity: a System API over SAP customer master, a System API over Salesforce, and an Experience API composing both into a customer 360 resource. Nothing is deployed and there is no Mule runtime behind it. It is a Postman mock server generated from the collection’s saved examples, and the requests are live HTTP calls from your browser.

Pick one, send it, and open the Tests tab.

No response yet. Hit Send.

The two error cases use a Postman-specific header, x-mock-response-code, which tells the mock which saved example to return:

curl -s https://162287a0-ded5-4ae6-bc37-466a1de86ba8.mock.pstmn.io/customers/CUST-1042/profile \
  -H "x-mock-response-code: 401"

The change in sequencing is what makes this worth doing. Write the spec, generate the mock, let the front-end team and the partner integrate against it, and implement the flows after that. An awkward response shape gets found while changing it is still free, rather than once three teams have shipped code against it. QA can write and run tests against the mock before the Mule flow exists, so QA and development run in parallel instead of one after the other.

Agents change what a contract has to say

A person retries a failed payment once, carefully. An agent retries it a thousand times in a second. An idempotency key stops being good practice and becomes the difference between a retry and a duplicated transaction. The same goes for error contracts: an agent cannot infer what an undocumented 4xx means, so it will do something confident and wrong.

That is the practical reason to write governance rules down. A rule requiring an Idempotency-Key header on every money-moving POST is a way of defining what “AI ready” means in a given organisation, and then enforcing it on every spec before merge rather than relying on people to remember.

Postman’s governance runs on Spectral, an open standard, so the rules stay portable to any Spectral-compatible tool rather than tied to a single vendor’s ruleset.

One more thing worth weighing. Mule is a proprietary language, so a model has far less public Mule XML and DataWeave to learn from than Java or Python. AI assistance in that stack is structurally weaker, and it stays weaker with each model generation. That shapes what is worth building in Mule and what is worth building in a mainstream language behind the gateway.

Where I would start

Not with a platform rollout. One API that is about to be built and is genuinely painful, ideally with an impatient consumer team attached.

1. Author the OpenAPI spec in Spec Hub. Enable a small governance ruleset, three or four rules you actually believe in. Push to Git through local mode and wire postman spec lint into the pull request.
2. Generate the mock and send the URL to the consumer team the same day, before a Mule flow exists.
3. Generate the collection from the spec. Add contract tests for the happy path and every documented error. Put the collection run in the pipeline as a gate, then schedule the same collection as a production monitor.
4. Publish that API to the Private API Network and invite a QA engineer and a product manager who have never had a reason to open Anypoint.

A few days of work on one API, and it leaves you with something concrete to point at rather than a slide: the consumer team integrated before the API existed, a contract regression was caught in CI rather than by a partner, and two people who had never opened Anypoint are doing useful work.

None of this requires a platform decision up front, which is the point. One API, one spec, one collection, one pipeline, and you will know within days whether the rest is worth doing. What you should not do is keep the two platforms in separate worlds, because that is the version where the collection gets exported by hand and everyone goes back to arguing about whose copy is current.

If you run MuleSoft and want to work through where this would fit in your own estate, or you think I have any of it wrong, reach out on LinkedIn. I am always up for that conversation.