Mock
Stand in for one API.
A mock is JavaScript that stands in for an API. It keeps state and can return errors, delays, and rate limits.
Postman Mock Servers deploy stateful mocks, written as code, to a stable URL on your team's domain, so other teams, CI, and coding agents can build and test without waiting on APIs.
世界中の導入企業
Install the Postman plugin and your agent gets mocking workflows it can run on its own: building a mock from your spec, collection, or code, and deploying it to a URL your team can call.
Marketplace
get the Postman plugin
claude plugin marketplace add anthropics/claude-plugins-officialclaude plugin install postman@claude-plugins-officialFind, build, and publish a stateful stand-in for one API
Find the APIs your service calls and reuse mocks their owners publish
Run assertions against a mock or a live API
Try these prompts
WHY POSTMAN
Teams wait on APIs that are unfinished, owned by another team, or stuck behind a shared staging environment. A Postman mock server gives them a stable URL for behavior that is available, predictable, and under your control.
Frontend, mobile, and service teams code and test against a stateful mock while the backend is still being built.
Deploy to a URL on your team's domain, and it stays the same even when you update the mock.
Each CI job, developer, or agent gets its own session, so parallel runs keep their own data.
Return delays, errors, and rate limits from the mock to check retries, fallbacks, and recovery paths.
Calls to the mock use no quotas, create no real data, and trigger no side effects. Use it in place of payment, identity, and partner APIs.
Request logs show each call and can be filtered by path, method, or status, so you can find the request that failed.
Collections, OpenAPI specs, and datasets become stateful mocks, and your coding agent can write the rest from your code.
NEXT STEP
Mock
A mock is JavaScript that stands in for an API. It keeps state and can return errors, delays, and rate limits.
Simulate
A simulation serves the mocks for your service's dependencies from one .sim.yaml file, behind one address.
Deploy
Other developers, CI, and agents use the same simulation on your team's domain instead of running their own.
Postman Simulator lets you build and test applications faster, against realistic API dependencies, without having to run every service.
モックサーバーによって、開発時の依存関係が解消されました。Postmanでは、APIの開発・テスト・リリースを並列で実行できます。APIの実装完了を待つ必要はありません。”
Eduardo Iriarte-Mendez氏
シニアソフトウェアエンジニア, Flix
Mocks are JavaScript in your repository that stand in for one API. A mock can keep state across requests and return scenarios such as delays, rate limits, and failures.
Mock servers help you deploy mocks to a stable URL on your team's domain, such as https://payments.mock.acme.postman.dev, so other teams, CI, and coding agents can use them. You control who can access a mock server, and each caller session gets its own state.
A simulation runs many mocks together, and the Postman Simulator page covers it. Mock servers cover HTTP APIs.
Push the mock with postman mock push, then deploy it with postman mock deploy and a slug. In the app, choose + > Mock Server > Existing mock. The CLI prints a sample request when you deploy a mock.
Mocks are available on all plans, and deploying needs a Solo, Team, or Enterprise plan (Postman pricing). The Learning Center covers building mocks with JavaScript and deploying a mock server, and the blog post Introducing Code-Based Mocks in Postman is a tutorial to start from.
Local and CI runs happen where you run the command. A deployed mock server is run by Postman, and you control who can access it. Signed-in Postman app and CLI sessions can call it, and other clients send a Postman API key in the x-api-key header. You can also make a mock server public, so anyone with the URL can call it. See Postman security.
Each caller sets an x-mock-session header, or uses the pm_mock_session cookie that Postman sets for you, and gets its own state. Sessions are on by default. You can turn them off for a shared demo where everyone should see the same data.
No. The URL, https://payments.mock.acme.postman.dev, stays the same when you update the mock, and the slug is kept when you redeploy. Turn on auto-deploy so the deployed server follows changes to the cloud mock.
Collection-based mock servers return the saved examples in a Postman collection, which suits documentation and quick demos. Postman mocks are code that keeps state, switches scenarios, and runs locally, in CI, or as deployed mock servers. Existing Collection-based mock servers keep working, and you can generate a code mock from the same collection.
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.
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.
See where API dependencies block your teams, and how to standardize mocks across local development, CI, and shared testing. You can also contact sales.