Application Inventory overview

Postman’s Application Inventory gives you visibility into the applications you build, the external APIs those applications depend on, and the test coverage validating those dependencies. By integrating with your existing UI test suite, the Application Inventory automatically captures API interactions during test runs, validates them against Postman Collections, and discovers dependencies. It does this without requiring any upfront instrumentation.

Postman provides first-class integration with Playwright UI tests through a dedicated network capture plugin. This integration allows you to transform existing Playwright test suites into comprehensive API validation workflows with minimal setup.

Your Postman workspace is tagged as an application, either automatically during onboarding or when you create an application in the Application Inventory. From that point on, every time postman app test runs (locally with CI=true or in CI/CD), test results and detected dependencies are pushed into Postman and surfaced in the Application Inventory UI.

Your modern UI tests already generate the most realistic API traffic your product ever produces, but that traffic is typically only visible in traces and logs after something breaks. That’s useful for debugging, but it isn’t validation. UI tests can pass even when the underlying API interactions have drifted from their contracts, because the UI handles the failure, caches stale data, or masks the degradation. The Application Inventory turns that network activity into actionable test evidence.

Who can benefit from the Application Inventory

The Application Inventory provides the most value to the following types of teams:

• An engineering team maintaining frontend or service applications that consume multiple internal APIs.
• A platform or quality team that needs a centralized view of application-to-API dependencies and test coverage.
• A team that already has a UI test suite (typically Playwright) but no structured way to validate the API layer those tests exercise.

Problems the Application Inventory solves

Application-to-API dependency relationships are usually undocumented or out of date. You have real traffic from UI workflows but no easy way to convert it into reusable Postman tests. The Application Inventory turns your existing UI test runs into a continuously updated source of API validation, dependency discovery, and cross-team traceability between consumers and producers.

More specifically, if you rely on UI assertions alone, you can miss a class of issues that the integration with Playwright is designed to catch:

• False positives — The UI looks correct, but the wrong endpoint was called, a call was missing, or the payload was wrong.
• Silent degradation — A backend error is translated into a generic UI fallback, so the test still passes.
• Contract drift — Schema, header, or content-type changes that don’t immediately break the UI go undetected.
• Poor diagnostics — Failures become guesswork; structured API captures turn them into clear, actionable evidence.

The Application Inventory workflow

The postman app test CLI command wraps your application’s existing UI test command. It observes the network traffic produced during the run, validates observed API calls against your Postman Collections using pm.test assertions, and pushes test results and detected dependencies into the Application Inventory.

From a single run it produces:

• A record of the UI tests that executed.
• A record of the API requests that were validated.
• A list of detected runtime dependencies — the external APIs the application called during the run.

The pipeline has four stages:

1. Capture — The Playwright plugin attaches to the browser context and streams structured request/response events (method, URL, timing, headers, and optional bodies).
2. Ingest — The postman app test command ingests the captured network calls.
3. Analyze — The CLI maps captured calls to collection requests using method, path, query, and optional body hints. For matched calls, Postman runs pm.test assertions against the observed responses. Unmatched calls are reported as coverage gaps.
4. Report — Results are surfaced in the terminal and pushed to the Application Inventory.

Over time, your collections evolve from recorded API calls into contract templates that validate real UI workflows.

Problem-solving patterns

The Application Inventory workflow is flexible and you can adapt it to different needs. Common patterns include:

• Validate an application that already has dependency collections — Run postman app init, review the generated config, then run postman app test locally or in CI. Results appear in the Application Inventory.

• Bootstrap collections from real UI traffic — Install the Playwright capture plugin, run postman app test --capture-only, refine the generated collection, then switch to the standard validate flow — or use an AI Agent to generate a dependency collection from the captured traffic.

• Multiple environments — Define additional targets in postman.config.cjs and run postman app test --target <name> per environment.

Agent Mode integration

The Application Inventory integrates with Postman’s Agent Mode to enable natural-language queries over your run data.

From the Application Inventory page, you can ask the agent to summarize the latest run results for a specific project. The agent will fetch the project summary, retrieve the latest run, pull detailed run information, and return a human-readable summary.

Next steps

Now that you understand the core concepts and workflow of the Application Inventory, you can get started by integrating your test suite with the feature. For step-by-step instructions, see Integrate your test suite with the Application Inventory.