Validate APIs During Your Playwright Tests with Postman

At the time of writing this article, Playwright ships over 8 million npm downloads a week, has over 88,000 GitHub stars, and lives inside 400,000+ repos on GitHub. It’s the default test runner for most new frontend projects in 2026.

But here’s the thing: every Playwright run already produces the most realistic API traffic your product makes, real auth, real payloads, real ordering, and almost every team throws it away. The UI test passes, the API layer underneath could be silently broken, and nobody notices until production.

We’re shipping two new Postman CLI commands and a Playwright plugin that fix that. You keep running Playwright the way you already do; Postman validates the API layer underneath in the same run.

Here’s the five-minute setup.

1. Link your repo to a Postman workspace

Make sure your project is already linked to a workspace through Postman’s native Git integration. If it isn’t, follow the setup guide first.

2. Install the CLI and the Playwright plugin

npm install -g postman-cli
npm install -D postman-playwright

3. Wrap your Playwright test fixture

Tell the plugin to attach network capture to your test fixture.

import { test as baseTest, expect } from '@playwright/test';
import { attachNetworkCapture } from 'postman-playwright';

const test = attachNetworkCapture(baseTest);

test('homepage has the expected title', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);
});

4. Initialize your application

In the root of your project, run:

postman app init

This is interactive. It asks which collections describe the APIs your app depends on, which environment to use, and which UI command to run. It writes the answers to postman.config.cjs in the root of your project. Commit it.

A typical postman.config.cjs looks like this:

module.exports = {
  command: 'npx playwright test',
  targets: {
    default: {
      environment: 'Local',
      collections: ['Event Service API'],
    },
    staging: {
      environment: 'Staging',
      collections: ['Event Service API'],
    },
  },
  filters: {
    urlPatterns: ['fonts.googleapis.com', 'fonts.gstatic.com', 'localhost:3007'],
    methods: [],
    headers: {},
  },
};

Targets are named runtime setups. The same repo can validate against default, staging, or prod without rewriting config, handy when you want different dependency surfaces in CI than on a developer laptop.

5. Run it

CI=true postman app test --command "npx playwright test"

CI=true makes the run non-interactive and pushes results to your workspace so they show up in Application Inventory. Without it, results stay on your terminal, useful while you’re iterating.

To run a different target:

postman app test --target staging

What you’ll see

In the terminal, you get a clear breakdown of:

• which Playwright tests passed
• which API calls were captured
• which captured calls matched a collection request, and whether their pm.test assertions passed
• which calls were unmatched (potential coverage gaps)

The same data lands in Application Inventory: a continuously-updated view of which APIs your application calls, which of those have test coverage, and which dependency contracts have drifted.

Keeping it usable: noise controls

Real apps are noisy. Fonts, analytics, hot-reload sockets, telemetry beacons, none of that should fail your build. Filter it out in postman.config.cjs:

filters: {
  urlPatterns: ['fonts.googleapis.com', 'localhost:3007', 'fonts.gstatic.com'],
  methods: ['OPTIONS'],
  headers: { 'x-client': 'analytics' },
},

Anything matching a filter is ignored before matching, so it can’t trigger an under- or over-coverage warning.

Don’t have API tests yet? Start by capturing them

The most common objection we hear is “we don’t have Postman collections for our APIs yet, so this isn’t useful to us.”

It is, and it’s the fastest way to get them.

postman app test --capture-only

In --capture-only mode, the CLI skips validation and instead generates a draft Postman collection from the traffic your UI tests produced. From there you can:

• review the captured requests and trim the ones you don’t care about
• ask Postman’s Agent Mode to generate pm.test assertions from the observed responses
• save the result as a real collection and switch to postman app test for ongoing validation

The same UI traffic that powers validation today becomes the foundation of a growing API contract suite over time. No one has to sit down and write the first hundred tests by hand.

What this catches that UI tests don’t

A quick gut-check on why this is worth wiring up:

• False green tests. UI looks correct, but the wrong endpoint was called or the payload is wrong.
• Silent degradation. A backend error gets swallowed by a graceful UI fallback. The test passes; the user experience is broken.
• Contract drift. Schema, header, or content-type changes the UI tolerates but downstream consumers won’t.
• Poor diagnosability. A flaky failure becomes a 30-minute trace dive. Structured request/response captures turn it into a one-line answer.

The bottom line

You already have UI tests. You already have an API layer. You already have the most realistic traffic your product produces, every time CI runs.

postman app test makes that traffic do real work: validate contracts, surface drift, document dependencies, and stop UI-green-but-API-broken bugs before they ship.

If you want to try it on a real codebase, install the plugin, run postman app init, and let your next Playwright run do double duty.

Resources

• the Postman CLI documentation
• Connect a Git project to your workspace
• Writing Postman test scripts
• Postman Agent Mode
• postman-playwright on npm