Powering API engineering for agents
The Postman plugin brings filesystem-first API development and organization-wide API context to coding agents. It enables agents to design, mock, test, document, monitor, and ship APIs directly from Claude Code, Cursor, and Codex. Every operation produces inspectable files or CLI commands that fit naturally into Git and CI, while the Postman Context Graph helps agents understand dependencies, ownership, runtime behavior, and the likely impact of a change.
Install Postman in every compatible coding agent detected on your machine:
npx @postman/postman-pluginOne command configures Claude Code, Codex, Cursor, Kimi Code, OpenCode and Pi.
Run it again to update, status to see what's installed, and remove to
uninstall; --agent <id> limits any of them to one agent.
You can also use the following commands to install individually:
View Postman on Claude Plugins
claude plugin install postman@postmanView Postman on the Cursor Marketplace
/add-plugin postman
View Postman on ChatGPT Plugins
codex plugin add postman@postmanView Postman in Pi's package gallery
pi install npm:@postman/postman-pluginpi update npm:@postman/postman-plugin updates it. Sign in to Postman's MCP
server with /mcp login postman inside a Pi session. The shell's pi mcp login
doesn't load extensions, so it reports no server named postman.
All postman resources have a filesystem representation, so your agent can work with the API ecosystem through the interface it understands best: files. API specifications, collections, environments, examples, mocks, documentation, and Flows can live beside the application code.
The git-native v3 collection schema makes this
especially agent-friendly. A collection is a directory tree under
postman/collections/, where every request, folder definition, and saved
example is its own YAML file. Environments use the same file-first model under
postman/environments/. HTTP, GraphQL, gRPC, WebSocket, Socket.IO, MQTT, MCP,
and LLM requests all have defined schemas the agent can follow.
That means the agent can:
- Read or change one request without rewriting a large collection export.
- Generate requests and examples directly from an API specification.
- Produce small, reviewable Git diffs and resolve changes with normal code review workflows.
- Lint and test the files locally before anything is shared with a Postman workspace.
A repository can show what an endpoint calls, but rarely who calls it, whether those consumers are active in production, where they are deployed, or which team owns them. The Context Graph fills that gap with a private, authenticated, organization-wide map of your API ecosystem.
It reconciles signals from the systems where API knowledge already lives:
- Postman workspaces: specifications, collections, monitors, and mocks
- GitHub: repositories, API definitions, and source-level call sites
- New Relic: deployments, runtime traffic, latency, errors, and telemetry
The api-discovery skill lets the agent start with the
thing you plan to change and ask one natural-language question:
postman context-graph ask "What could break if we change the billing API?" --waitThe graph discovers the surrounding scope—including repositories that are not checked out locally—before the agent starts editing code. It refreshes nightly as services, deployments, ownership, and runtime relationships change.
In Postman's controlled benchmark across 468 repositories, starting with this map used up to 74% fewer tokens, 52% fewer tool calls, and 72% lower cost. Accuracy also improved in 18 of 21 scored prompt-model pairs. Most graph queries completed in roughly 20–40 seconds. Read the methodology and results in Introducing the Context Graph API: One Map of Your API Ecosystem.
The api-mocking skill creates a working mock from an
OpenAPI specification or collection and stores the implementation beside the
API code. The agent can run it locally, add success and failure scenarios, and
test consumers without waiting for the real service to be ready or available.
The mock stays local until you choose to push and deploy it. When teammates or external systems need access, the same mock can become a durable hosted URL without rebuilding it in another tool.
Some Postman CLI commands report usage analytics by default. Where supported,
you can disable reporting for an individual command with
--no-report-events. postman application test uses
--report-events=false instead.
What is sent by default:
| Command | Data sent |
|---|---|
postman collection run |
Run analytics and run history |
postman application test |
Run results and analytics |
postman spec lint |
Lint analytics, including violation counts and pass/fail |
postman workspace push |
Push analytics |
postman runner start |
Runner analytics |
postman flows run |
Flow-run analytics |
postman request |
Request analytics |
Important limits:
postman collection run --no-report-eventsdisables analytics but does not disable run-history uploads.postman initmakes richer reporting opt-in with--report-events; it does not accept--report-events=false.- The CLI also sends a minimal, unauthenticated event indicating that certain
commands ran. Reporting flags do not disable these client events. They are
emitted by
collection run,spec lint,workspace push,init, themockcommands, andperformance runin the US region; other regions, including the EU, do not emit them. - The plugin registers Postman's hosted MCP server as a fallback when the CLI cannot run. MCP tool calls reach Postman and are not controlled by CLI reporting flags; avoiding that traffic requires not installing the MCP server.
Apache-2.0 — see LICENSE.
