What’s new in Postman: AsyncAPI 3.0, performance streaming, and service accounts

This was a packed week for the Postman platform. Five features shipped that touch almost every part of the API lifecycle — from how you design event-driven APIs, to how you validate specifications, to how you stress-test services in your CI/CD pipeline. I’ve been digging into each one, and a few of these are going to change daily workflows for a lot of teams.

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

AsyncAPI 3.0 gets first-class support in Spec Hub

If you’re building event-driven systems with Kafka, MQTT, WebSockets, or any message broker, this one matters. Postman now supports AsyncAPI 3.0 specifications with the same editing, validation, and preview experience you’re used to with OpenAPI.

The 3.0 release of AsyncAPI was a significant rewrite. It decoupled channels from operations, making specifications reusable and less ambiguous than the 2.x versions. That cleanup is what made broad tooling support practical — and now Postman is there.

What you can do

You can create AsyncAPI 3.0 specifications directly from the left sidebar, the + New menu, or through Postman Agent Mode. The import flow accepts v3 files through file upload, folder, link, or paste — the same paths you’d use for any other specification type.

The editor provides v3-specific validation, snippets, and $ref autocomplete. There’s a v3-aware sidebar outline that includes top-level Operations (a concept that didn’t exist as a standalone entity in v2). And the shared AsyncAPI live preview renders your documentation as you type.

Local workspaces also auto-detect v3 specification files on disk, so if you’re using Native Git workflows, your AsyncAPI 3.0 files show up without extra configuration.

Unified diagnostics pane for API specifications

The per-workbench validation pane is gone. In its place: a single, centralized diagnostics pane that consolidates all validation issues across every open API specification and Common Component tab.

This is one of those changes that sounds incremental but shifts how you work. Instead of switching between tabs to check each specification’s validation state, you get a single view with everything — errors, warnings, info messages — organized into a navigable tree grouped by file and rule source (syntax versus governance rules).

The status bar indicator

There’s a new status bar indicator at the bottom of the editor that shows real-time error, warning, and info counts for whichever tab you’re looking at. Click it, and you jump directly to the diagnostics pane filtered to that tab’s issues.

You can also toggle severity levels independently. Working through a governance rollout and want to focus on errors first? Turn off warnings and info. Come back to them later.

Move API specifications between workspaces

You can now move API specifications across workspaces the same way you’ve always moved collections. Open the specification options menu, select Move, choose a destination workspace, and done. Structure, metadata, and multi-file relationships all come along.

This works for every specification type Postman supports: OpenAPI 2.0, 3.0, and 3.1, AsyncAPI 2.0, GraphQL, and protobuf. Single-file and multi-file specifications both work.

It’s a small feature, but it removes a real friction point. I’ve seen teams duplicate specifications across workspaces because there was no move option — then struggle to keep them in sync. Now you can reorganize without that overhead.

Live streaming for CLI performance runs

This is the one that got the most internal excitement, and I get why. You can now trigger performance runs from the Postman CLI and watch results stream in real time in Postman.

Before this, running performance tests from a CI/CD pipeline meant waiting for the full run to complete before seeing any results. If your API failed 10 seconds in, you still waited for the entire test duration to elapse. That’s wasted pipeline time and delayed feedback.

How it works

Run your performance test from the Postman CLI using the postman performance run command — either locally or from your CI/CD pipeline. While the test runs, open Postman and you’ll see a live stream of response times, throughput, and error rates updating in real time.

The practical value here goes beyond watching graphs update. If an API breaks immediately under load, your team can stop the run and adjust without burning through the remaining test duration. That matters when your CI/CD pipeline is blocking a deploy.

Quality gates in your pipeline

The Postman CLI can also act as an automated quality gate. Define your thresholds — response time SLAs, maximum error rates, minimum throughput — and the Postman CLI returns a non-zero exit code if the run fails to meet them. Your pipeline stops the build before it reaches production.

This follows the broader industry shift toward integrating performance testing directly into CI/CD rather than running it as a separate, post-deployment step. The difference is catching regressions before they ship, not after.

Available to all Postman Solo plan and above customers.

Try it in your pipeline

Here’s what the Postman CLI integration looks like in a GitHub Actions workflow:

- name: Run performance tests
  run: |
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman performance run <collection-id> \
      --environment <environment-id> \
      --virtual-users 50 \
      --duration 300

The exit code tells your pipeline whether the run passed or failed, so you can gate deployments on performance results without writing custom scripts.

Service accounts for Enterprise teams

Service accounts give Postman Enterprise teams a non-human identity for automation, integrations, and system-to-system interactions. If you’ve been using a team member’s personal API key for CI/CD integrations, this is the proper replacement.

The security model uses short-lived JWT tokens. You exchange a service account API key for a token that’s valid for 15 minutes, and that token encodes the account’s identity and permissions. No more long-lived credentials sitting in your pipeline configuration.

The API endpoint

There’s a single endpoint:

POST /service-account-tokens
Authorization: Bearer <service-account-api-key>
Content-Type: application/json

The response gives you a short-lived access token:

{
  "token": "eyJhbGciOiJSUzI1NiIs...",
  "expires_in": 900,
  "token_type": "Bearer"
}

Use that token for your automated Postman API calls. When it expires, request a new one. The endpoint is rate limited to 10 requests per 10-second window per user, which is plenty for any automation pattern that isn’t doing something wrong.

Why this matters

Non-human identity management has become a critical concern as teams automate more of their API lifecycle. The two main risks with using personal API keys for automation are: the key has broader permissions than the automation needs, and the key stops working when that person leaves the team.

Service accounts solve both. You scope the permissions to what the automation actually requires, and the account isn’t tied to any individual’s employment status. Combined with short-lived tokens, the blast radius of a compromised credential shrinks from “everything that person has access to, indefinitely” to “a narrow set of permissions, for 15 minutes.”

This is Enterprise plan only.

Also in this release: Postman API v1.41.0

Alongside service accounts, the Postman API v1.41.0 adds AsyncAPI 3.0 support to the /specs endpoints. If you’re managing specifications programmatically, you can now create, read, and update AsyncAPI 3.0 specifications through the API — not only through the app.

What these updates add up to

Individually, each of these features fills a specific gap. Together, they tell a story about where Postman is heading: tighter feedback loops (live performance streaming), broader protocol coverage (AsyncAPI 3.0), better developer experience for specification management (unified diagnostics, cross-workspace moves), and proper infrastructure for automation at scale (service accounts).

The AsyncAPI 3.0 support is particularly interesting if you’re working in a hybrid architecture — REST APIs alongside event-driven services. Having both OpenAPI and AsyncAPI specifications in the same workspace, with the same validation and editing experience, means one fewer tool in your stack.

Start with whatever’s most relevant to your current work. If you’re running performance tests in CI/CD, try the live streaming. If you’ve been waiting on AsyncAPI 3.0 support, create your first specification in Spec Hub. If you’re an Enterprise team with personal API keys in your pipelines, swap them out for service accounts.

Resources

• Design API specifications in Postman — Spec Hub documentation
• AsyncAPI 3.0 specification — full reference
• Configure and run performance tests — performance testing docs
• Run a performance test using the Postman CLI — CLI performance run reference
• Simulate user traffic to test API performance — performance testing overview
• Manage workspaces — workspace management, including moving elements
• API governance overview — governance and validation rules
• Generate and use Postman API keys — API authentication docs