Postman Simulator
Postman Simulator lets you build and test applications faster, against realistic API dependencies, without having to run every service.
Built for coding agents and the developers who work with them.
Trusted by teams at
Give your coding agent the skills to build and run simulations
Install the Postman plugin and your agent gets simulation workflows it can run on its own: mocking the APIs your service calls, running your service against them, and making them fail.
Marketplace
get the Postman plugin
claude plugin marketplace add anthropics/claude-plugins-officialclaude plugin install postman@claude-plugins-officialapi-simulation
Run your service against mocks of its HTTP dependencies, and make them fail
api-mocking
Find, build, and publish a stateful stand-in for one API
api-discovery
Find the APIs your service calls and reuse mocks their owners publish
api-testing
Run assertions against a mock or a live API
workspaces
Connect your repository to a Postman workspace to review the results
Try these prompts
WHY POSTMAN
Simulations built for developers and agents
Your service calls APIs that are unfinished, owned by another team, or stuck in a shared staging environment. Postman Simulator runs your service against stateful mocks of them, so you and your coding agent build against APIs that are available, predictable, and under your control.
Catch your agent's wrong assumptions
An agent can write code and tests from the same wrong assumption. A mock from the API's contract or its owner gives it behavior to test against.
Agents pick up where they left off
Each simulation records what the agent assumed, what it observed, and where each fact came from. The file lives in your repository, so you can review it in a pull request.
Test without running every service
One .sim.yaml file runs the mocks for the APIs your service calls, behind one address. Several agents can run their own at once.
Test failures before customers see them
Add a 503, a delay, or a rate limit to any mock for a single run, and test the failure paths staging never produces.
Send other calls to the real services
In proxy mode, calls to the hosts you mock go to their mocks, and everything else goes to the real service. Proxy mode needs an origin set on each mock, and proxied calls can change real data.
Reuse mocks other teams publish
The API team publishes its mock once. Add it to your project as a dependency and stay current.
Deploy a simulation at a stable URL
Other developers, CI, and agents use the same simulation on your team's domain instead of running their own.
Frequently asked questions
Postman Simulator runs your service against simulated versions of the APIs it calls, so you can build and test without running every service. A simulation is a .sim.yaml file in your repository. It lists the mocks to run and how requests are routed to them, and it runs the same way in the Postman app, the CLI, CI, and through a coding agent. A mock stands in for one API, as code. It can keep state across requests, so when your service retries a payment, the payments mock stores a second charge. Simulations cover HTTP APIs and don't replace a final check against real services.
Install the Postman CLI with npm install -g postman-cli and run postman init in your repository. Then ask your agent: "Mock the APIs this service calls, run the service against them in a simulation, then make one of them fail and show me how the service handled it."
Prefer to work in the Postman app? The Learning Center covers the same steps: Simulate API conditions with Postman Simulator, Create a simulation, and Simulator in the CLI.
No. Developers create, edit, and run mocks and simulations in the Postman app or with the Postman CLI. Coding agents use the same files and commands, so you can start without an agent and add one later. Claude Code, OpenAI Codex, Cursor, Gemini CLI, Factory, and OpenCode work through the Postman plugin and skills.
You choose. A simulation serves mocks for the APIs you pick. In proxy mode, set the origin in each mock's config.yaml and trust the Simulator's CA certificate, and your service keeps its real URLs: calls to a mocked host go to its mock, and other calls go to the real services. The service you are building is not part of the simulation.
Requests that pass through the proxy reach real services and can change real data, so point them at test environments.
Yes. Each mock has named scenarios. Add an error such as a 503, a delay, or a rate limit to any mock and run again. You can override the conditions for a single run without changing the saved scenario, and the request log shows how your service handled each call.
Mocks come from your OpenAPI spec or collection, or from the team that owns the API and publishes them. Each simulation's context file records the sources and what has and has not been verified. Simulations let you test more conditions earlier and do not replace a final check against real services.
Yes. The .sim.yaml file lives in your repository. Start it with postman simulation run ./postman/simulations/checkout/checkout.sim.yaml, then run your tests against its address. The same command works in CI. Mocks are available on all plans. To let other developers, CI, and agents share a simulation instead of running their own, deploy it to a URL on your team's domain. Deploying needs a Solo, Team, or Enterprise plan (Postman pricing). The Postman Mock Servers page covers deployed URLs.
Postman mocks are JavaScript files in your repo that keep state and switch named scenarios, and the team that owns an API publishes one mock that every consumer reuses. Keep using staging for the services that are stable, and simulate the ones that are unstable, missing, or owned by another team.
Moving from another mocking tool: static routes and examples carry over through an OpenAPI spec, and your agent can rewrite stateful behavior as code. Review the result before you rely on it.
Talk to a Postman expert
See where API dependencies block your teams, and how to run simulations across local development, CI, and shared testing. You can also contact sales.