> For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://learning.postman.com/llms.txt.
# Integrate your test suite with the Application Inventory
Application Inventory is available on Postman Solo, Team, and Enterprise plans. For more information, see the [pricing page](https://www.postman.com/pricing/).
Postman's Application Inventory integrates with your existing UI test suite to validate API interactions and discover dependencies automatically. This guide walks through setting up your first application and running tests with network capture.
The exact integration flow depends on whether you're connecting your workspace or linking an application to an existing workspace. The key difference is that for new workspace connections, the setup process is guided and happens automatically when you link your repository.
For existing workspace connections, you need to create an application from the Application Inventory and [initialize your application using `postman app init`](#step-5-initialize-and-run-your-application-tests) to complete the setup. To access the Application Inventory, click 
**Home** in the Postman sidebar and select 
**Application Inventory**.
## Step 1: Link your application to a workspace
You have to be on your Postman desktop app to complete this step.
To connect your application repository to a Postman workspace, do the following:
1. Navigate to your Postman workspace.
2. If not already linked, connect your repository. From the Postman sidebar, click 
**Files > Open folder**. See [Connect your Git project to your workspace](/docs/use/native-git/setup#connect-your-git-project-to-your-workspace) for more details on Postman's Git integration.
3. Complete the repository linking process.
If Postman detects Playwright tests in your code during the linking process, it automatically adds the `application` workspace tag to the Application Inventory.
## Step 2: Install the Postman CLI
Install the latest version of the Postman CLI if you don't already have it:
```bash
npm install -D postman-cli
```
## Step 3: (Optional) Add API tests to your workspace
If you already have Postman Collections that represent your API contracts, add them to your workspace. To learn more about writing tests in Postman, see [Write scripts to test API response data in Postman](/docs/tests-and-scripts/write-scripts/test-scripts).
## Step 4: Set up the capture plugin
Install the [Postman Playwright plugin](https://www.npmjs.com/package/postman-playwright):
```bash
npm install -D postman-playwright
```
You can enable network capture in one of two ways. Postman recommends using `withPostman` because it requires only a one-time configuration change and works across all pages, contexts, and fixtures.
### Recommended: Enable capture in your Playwright config
Add `withPostman` to your Playwright configuration:
```ts
// playwright.config.ts
import { defineConfig } from '@playwright/test';
import { withPostman } from 'postman-playwright';
export default withPostman(defineConfig({
// Your existing Playwright configuration
}));
```
The `withPostman` function enables Playwright's built-in JSON reporter and trace recording. The Postman CLI reads these artifacts (`playwright-report.json` and `trace.zip`) to analyze network traffic. No changes to your test code or custom data pipeline are required.
This approach requires only a one-time configuration change and provides broader capture coverage. However, test runs might take longer because Playwright must generate and store JSON reports and trace data.
### Alternative: Enable capture in test files
You can also enable capture by wrapping Playwright's `test` object with `attachNetworkCapture`:
```ts
import { test as baseTest, expect } from '@playwright/test';
import { attachNetworkCapture } from 'postman-playwright';
const test = attachNetworkCapture(baseTest);
test('has title', async ({ page }) => {
await page.goto('https://playwright.dev/');
await expect(page).toHaveTitle(/Playwright/);
});
```
This approach has lower runtime overhead because it doesn't rely on Playwright trace artifacts. However, it requires updating each test file or creating a shared wrapper that re-exports the wrapped `test` object.
The `attachNetworkCapture` function only captures traffic from Playwright's built-in `page` object. The function won't capture traffic from pages created manually inside a test, such as pages created with `browser.newContext()` and `context.newPage()`.
For example, network traffic from this manually created page won't be captured by `attachNetworkCapture`:
```ts
test('creates a page manually', async ({ browser }) => {
const context = await browser.newContext({
recordVideo: { dir: './videos/' },
});
const page = await context.newPage();
});
```
## Step 5: Initialize and run your application tests
Initialize your project as an Application Inventory application and run your tests.
### Initialize your application
Run the initialization command to set up your project:
```bash
postman app init
```
This command does the following:
* Analyzes your project's file structure.
* Allows you to select your test command, collections, and environment for your default target.
* Creates a `postman.config.cjs` file that links your application to Postman.
* Declares the UI test command, available targets, and filter rules for captured traffic.
Review the generated `postman.config.cjs` to ensure the configuration matches your project structure.
### Filter out irrelevant traffic
To exclude irrelevant URLs, methods, and headers, update the `filters` configuration in `postman.config.cjs`. You can pass a single object (applied to all tests) or an array of scoped entries.
**Single object** that applies to all tests:
```javascript
filters: {
urlPatterns: ['fonts.googleapis.com', 'localhost:3007', 'fonts.gstatic.com'],
methods: [],
headers: {},
},
```
**Scoped array** where each filter can target specific tests by file path (`target`, matched as a regex) or Playwright tags (`tags`):
```javascript
filters: [
// Applied to all tests
{
urlPatterns: ['fonts.googleapis.com', 'fonts.gstatic.com'],
},
// Applied only to tests matching the path regex
{
target: 'tests/checkout\\.spec\\.ts',
urlPatterns: ['sentry.io'],
},
// Applied only to tests tagged @checkout
{
tags: ['@checkout'],
urlPatterns: ['analytics.example.com'],
},
],
```
Each filter in the array is evaluated against the test. If a request matches any filter's rules, it's excluded from validation. Filters with no `target` or `tags` apply to all tests.
Tag-scoped entries (`tags`) are only applied when capture is [enabled in your Playwright configuration](#recommended-enable-capture-in-your-playwright-config). When capture is [enabled in test files](#alternative-enable-capture-in-test-files), tag-scoped entries are ignored, but entries scoped by `target` still apply.
### Run the tests
Run your UI tests using the Postman CLI:
```bash
postman app test
```
For local testing, use the `--report-events` option to capture test results and analytics in the Application Inventory:
```bash
postman app test --report-events
```
Collections and environments are selected from the targets defined in `postman.config.cjs`. You can override them at runtime using the `--target`, `--target-environment`, and `--target-collection` options.
You can use the `--network-log` option to analyze previously captured network traffic from a Playwright JSON report, network capture file, or artifact directory. This enables you to run validation and coverage analysis against a specific test run without relying on automatic artifact discovery.
Git metadata is automatically captured for each test run. This includes the commit ID, tags, parent commits, `git describe` output, Git notes, and whether the working tree has uncommitted changes. No additional configuration is required. This makes it possible to see which state of your codebase each test run relates to, and to identify release builds by tagged commits or your own tag naming convention. In CI environments, the command also captures Git metadata from supported CI providers when available.
Results appear in the terminal. If you are logged in and the workspace has been added to the Application Inventory, results are also pushed to the Application Inventory.
Postman collects test results automatically only in CI environments. For local testing, Postman only collects data if the `--report-events` option is used.
## (Optional) Bootstrap collections from captured traffic
If you don't have existing API tests, you can generate collections from observed network traffic:
```bash
postman app test --capture-only
```
This workflow:
* Captures traffic during UI test runs.
* Generates a draft Postman Collection from observed requests.
* Uses AI to help create assertions from captured responses.
* Allows you to refine the tests and reuse them in future runs.
The same UI traffic that validates your APIs can become the foundation for a comprehensive API contract suite.
## Next steps
You can view your test results and discovered dependencies in the Application Inventory. Click **Home** in the Postman sidebar and select **Application Inventory**.