# What’s new in Postman: Flows, Fabric Gateway, and Astro AI

> Source: <https://blog.postman.com/whats-new-in-postman-flows-fabric-gateway-and-astro-ai/>
> Published: 2026-10-12 16:00:00+00:00

# What’s new in Postman: Flows, Fabric Gateway, and Astro AI

Five updates landed across the Postman platform in the first two weeks of September, and together they touch almost every stage of building and running APIs and agents: test coverage, AI gateway infrastructure, agent access control, performance testing at scale, and the protocols you can drive from a visual canvas.

Here’s what shipped and how to start using it.

## Application Inventory adds trends, insights, and a compare view

[Application Inventory](https://learning.postman.com/docs/tests-and-scripts/test-applications/overview) tracks which APIs your application calls and whether those calls have test coverage. It does this by capturing network traffic during your UI test runs and validating it against your Postman Collections. Until this update, it opened on whichever environment you’d looked at last, so if your test data lived in a different tab, the page looked empty and the counts read zero.

It now opens on every environment at once. Every application gets a real count on first load, with a tab per environment and never-run applications grouped at the bottom.

Three new views sit alongside the dependency list you already had:

- Insights surfaces findings worth acting on: error responses that were never asserted, or endpoints that show up in captured traffic but are missing from any collection.
- Trends charts total tests, failing tests, and pass rate over up to twelve months, with deployed versions marked on the timeline. Drag to select a window, and the run list filters down to just the runs inside it.
- Compare baselines one branch, git tag, or commit against another, with the Workflows, APIs Consumed, and API Tests cards showing the deltas between them.

There’s also a Workflows tab where you can expand a UI test to see the API calls it made, with a toggle that pivots the view to endpoints instead. That makes “what tests this endpoint?” as direct a question as “what did this test touch?” A Dependencies tab shows new, tested, and untested endpoint counts for any entry you expand.

None of this changes how you send data to Application Inventory. If you’re already running the Postman CLI against your Playwright suite, your existing runs show up with no changes:

```
postman app test --target staging --deployed-version 2.4.1
```

The `--deployed-version` flag is what lines up the Trends timeline with your releases. Skip it, and you still get the trend data, just without version markers to correlate against.

Application Inventory is available on Solo, Team, and Enterprise plans. If you haven’t connected a UI test suite yet, the [Application Inventory overview](https://learning.postman.com/docs/tests-and-scripts/test-applications/overview) walks through the setup, and I covered the initial [Playwright integration](https://blog.postman.com/postman-playwright-integration-testing-ui-and-api-together/) when it first shipped.

## Fabric Gateway’s cloud version reaches general availability

[Postman Fabric Gateway](https://www.postman.com/fabric-gateway/) is the control plane for routing and governing traffic to AI models, MCP servers, agents, and internal APIs. It now has a dedicated cloud domain at [app.fabricgateway.ai](https://app.fabricgateway.ai/), with both the control plane and the data plane running in Postman Cloud, and the data plane now supporting multiple tenants on the same infrastructure.

You can sign up with an email and password instead of going through a separate provisioning process, and team management, inviting members and setting access, is built into the same flow. If you’re coming from the self-hosted version at [fabric.postman.com](https://fabric.postman.com), that instance is migrating over, with Postman’s production data plane pointing at the new control plane.

This release was for Team plans. A few weeks later, the broader public launch landed with the full control plane: an admin API, certificate-based node enrollment, and [identity-based access control](https://auth0.com/blog/access-control-in-the-era-of-ai-agents/) across org, team, and agent. That GA announcement got coverage from [SD Times](https://sdtimes.com/control-plane/postman-introduces-the-control-plane-for-the-agentic-world-with-general-availability-of-fabric-gateway/) and [Help Net Security](https://www.helpnetsecurity.com/2026/09/29/postman-fabric-gateway/), among others.

If you’re routing agent traffic through more than one model provider today, the [Fabric Gateway architecture docs](https://docs.fabricgateway.ai/get-started/architecture) explain how the control plane and data plane split responsibilities, and why running your own data plane keeps credentials and traffic inside your cloud account instead of a shared one.

## Astro AI ships fine-grained access control

Postman’s Astro AI platform, where you push blueprints and deploy agents, now has fine-grained access control (FGA) in production. Roles apply to three resource types: blueprints, deployed agents, and knowledge stores.

The model is restricted by default. When you push a blueprint, deploy an agent, or create a knowledge store, you become its admin, and nobody else can view, edit, operate, or otherwise touch that resource until you explicitly assign them a role. That applies retroactively too. Every existing blueprint, deployment, and knowledge store now needs its admin to grant roles before teammates get access again.

If you manage agents that other people on your team depend on, set aside time right after reading this to audit who needs access to what. Restricted-by-default is the right long-term call, and it matches the [least-privilege approach](https://auth0.com/blog/access-control-in-the-era-of-ai-agents/) that’s becoming standard for agent authorization generally, but it does mean a one-time cleanup if your agents already have other users relying on them.

The [knowledge store docs](https://docs.astropods.com/knowledge-stores) cover how roles interact with shared data stores specifically, since those are the resource most likely to be shared across several agents at once.

## Performance testing on Postman Cloud reaches general availability for Enterprise

[Performance testing on Postman Cloud](https://learning.postman.com/docs/tests-and-scripts/performance-testing/testing-api-performance) has been generally available (GA) for Solo and Team plans for a while. It’s now extended to Enterprise. Postman provisions the workers, distributes the load, streams live metrics, and stores the report. Your collections, scripts, assertions, and local workflows don’t change at all.

Enterprise gets one capability the other plans don’t: static IPs as an egress routing strategy. Instead of requests coming from Postman’s shared, dynamic IP pool, they come from a fixed set of addresses, so cloud-generated load can reach APIs sitting behind an IP allowlist. That matters for anything touching production infrastructure where the gateway or firewall only accepts traffic from known addresses.

Running a performance test from CI/CD looks the same regardless of plan:

```
postman performance run <collection-id> \
  --environment <environment-id> \
  --virtual-users 50 \
  --duration 300
```

The [Postman CLI performance run reference](https://learning.postman.com/docs/postman-cli/postman-cli-run-performance-test/) covers the full set of flags, including how to set response time, error rate, and throughput thresholds that fail the build when they’re breached. On Enterprise, the difference is entirely in the networking, not the command.

## Flows adds GraphQL and gRPC requests

[Postman Flows](https://learning.postman.com/docs/postman-flows/overview) already ran HTTP and AI requests from the canvas. It now runs GraphQL and gRPC requests too. Search your collection from the canvas, select a request, and the block behaves the way request blocks already do: configure inputs through the Variables ports, and the response comes back through a Success or Fail output port depending on the status.

Test scripts work exactly like they do for HTTP, so the validation patterns you already know carry over directly. Here’s a script checking a GraphQL response for a `user` object with the fields you expect:

``` js
const response = pm.response.json();

pm.test("Query returned a user object", function () {
    pm.expect(response.data).to.have.property("user");
    pm.expect(response.data.user).to.have.property("id");
    pm.expect(response.data.user).to.have.property("email");
});
```

For a gRPC request, the response shape depends on your `.proto` definition, but the assertion pattern is identical:

``` js
const response = pm.response.json();

pm.test("User lookup returns an active account", function () {
    pm.expect(response.status).to.equal("ACTIVE");
    pm.expect(response.userId).to.be.a("string");
});
```

Chain a few of these blocks together, and you’ve built a flow that calls a GraphQL mutation, waits for the result, then fires a gRPC request to confirm the downstream service picked up the change. All of that without leaving the canvas or writing a raw HTTP request by hand.

This is available on every plan, including the free plan. If you’ve been keeping GraphQL and gRPC checks in separate scripts outside Postman because Flows only spoke HTTP, this closes that gap. The [API protocols overview](https://learning.postman.com/docs/use/send-requests/protocols/protocols) covers what’s supported where, and the [gRPC client docs](https://learning.postman.com/docs/sending-requests/grpc/grpc-client-overview) are the right next stop if you haven’t made a gRPC call in Postman outside of Flows yet.

## Where to start

These five updates point in the same direction: more visibility into what you’ve built, tighter control over who can touch it, and more infrastructure to run it at scale across more protocols. None of them require you to change anything you’re already doing. They add capability on top of workflows that already work.

Start with whichever one removes a blocker you have today. If you’ve been testing GraphQL or gRPC services outside Postman because Flows couldn’t reach them, that’s the fastest win. If you run an Enterprise team with agents other people depend on, the Astro AI access change needs a look regardless of whether you were planning to touch it this week.

## Resources

- [Application Inventory overview](https://learning.postman.com/docs/tests-and-scripts/test-applications/overview) (Postman Docs)
- [Postman CLI application commands](https://learning.postman.com/docs/postman-cli/postman-cli-application) (Postman Docs)
- [Postman Playwright integration](https://blog.postman.com/postman-playwright-integration-testing-ui-and-api-together/) (Postman Blog)
- [Postman Fabric Gateway](https://www.postman.com/fabric-gateway/) (Postman)
- [Fabric Gateway architecture](https://docs.fabricgateway.ai/get-started/architecture) (Fabric Gateway Docs)
- [Astro AI knowledge stores](https://docs.astropods.com/knowledge-stores) (Astro AI Docs)
- [Performance testing on Postman Cloud](https://learning.postman.com/docs/tests-and-scripts/performance-testing/testing-api-performance) (Postman Docs)
- [Postman CLI performance run reference](https://learning.postman.com/docs/postman-cli/postman-cli-run-performance-test/) (Postman Docs)
- [Postman Flows overview](https://learning.postman.com/docs/postman-flows/overview) (Postman Docs)
- [API protocols in Postman](https://learning.postman.com/docs/use/send-requests/protocols/protocols) (Postman Docs)
- [gRPC client overview](https://learning.postman.com/docs/sending-requests/grpc/grpc-client-overview) (Postman Docs)
- [Access control for AI agents](https://auth0.com/blog/access-control-in-the-era-of-ai-agents/) (Auth0 Blog)