Written by the Apidog team. This is the page to read after you have decided to move and want to know what each thing you use in Postman becomes. Where there is no equivalent, it says so.
Switching tools is easier when you can name the mapping. Here is every major Postman feature, what it becomes in Apidog, and what changes in practice. Postman plan details are from postman.com/pricing on September 8, 2026.
The map
| Postman | Apidog | What changes |
|---|---|---|
| Workspace | Team and project | A project holds one API's spec, requests, mocks, tests, and docs together |
| Collection and folders | Project folders and endpoints | Import keeps the structure; endpoints are spec-backed, not free-form requests |
| Request | Endpoint case | Cases live under a designed endpoint, so parameters and schemas are shared |
| Environments and variables | Environments; global, environment, and local variables | Same model; team-level shared variables on Professional |
Pre-request and test scripts (pm.*) |
Pre-processors and post-processors, with pm.* support |
Imported scripts run unchanged |
| Collection Runner | Test scenarios | Scenarios chain cases, pass values between steps, and add visual assertions |
| CSV/JSON data in the runner | Data table on a scenario | Same idea, attached to the scenario in the UI |
| Flows | Test scenarios plus branching steps | Flows do not export; rebuild them as scenarios |
| Mock servers | Smart mock | Generated from the response schema with no setup; expectation rules by parameter; local by default, cloud optional |
| Monitors | Scheduled tasks on a self-hosted runner | Active checks from your runner with notifications; not multi-region |
| Newman and the Postman CLI | Apidog CLI | Runs scenarios in GitHub Actions, GitLab CI, and Jenkins; also manages project resources |
| Published documentation | Published docs site | Generated from the spec you test against; custom domain, versions, "try it" console |
| Postbot and AI credits | Apidog AI features | No credit meter |
| API Builder and schemas | Visual OpenAPI designer and reusable schemas | Design is the source, not a sidecar |
| Version control (forks, merges) | Sprint branches, protected main branch, merge requests | Admin review before changes land on the shared spec |
| Roles and permissions | Member roles at team and project level | Similar model |
| SSO, SCIM, audit logs (Enterprise, $49) | SAML SSO, SCIM, audit logs with API (Enterprise, $27) | Same controls at a lower seat price |
| Public API Network | API Hub | Apidog's is a catalog of published APIs, not a public marketplace |
| Private API Network | API Hub and multiple docs sites | Not a portfolio-wide inventory; a real gap for large enterprises |
The rows that need explaining
Collections become spec-backed endpoints. In Postman a request is a free-form thing. In Apidog it is a case under an endpoint that has a defined schema, so the mock, the docs, and the schema assertions all read from the same place. The import creates the endpoints from your collection; the first thing worth doing afterwards is cleaning the generated spec so it becomes the source of truth.
Flows are the one thing that does not import. Postman Flows have no export format. Most Flows are either a chained sequence (which becomes a scenario with values passed between steps) or a conditional (which becomes a scenario with branching steps). Budget one to three hours per Flow.
Monitors become scheduled tasks, with a caveat. Apidog's scheduled tasks run scenarios on a timer from a self-hosted runner and notify on failure, which covers the common "run the smoke suite every hour" use. They do not run from several regions and they are not passive observability. If that is what your Monitors do, keep them or move the job to a monitoring tool.
Mock servers get simpler. In Postman you define examples and point a mock at them. In Apidog the mock exists the moment the endpoint has a response schema, with realistic Faker.js data by field name, and you add expectation rules for specific inputs. Local by default, so a frontend developer can run it on their machine.
Docs stop drifting. Postman publishes documentation from the collection. Apidog publishes from the spec that the tests assert against, so the docs cannot describe a field the API no longer returns.
Two rows have no equivalent. The public API Network and passive multi-region monitoring. Decide on those before you switch; the trade-offs are laid out in Apidog vs Postman.
What is new, with no Postman equivalent
- Database steps in tests: query SQL (free plan) or NoSQL (Basic) inside a scenario to confirm a write.
- Self-hosted runner, EU region, on-premises edition. Postman is cloud only.
- MCP server for the published docs, so Cursor or Claude Code can read your API spec as context.
- Four free users with unlimited runs and mocks.
Doing the migration
Export collections and environments as JSON from Postman, import into an Apidog project, check the scripts, promote the spec, rebuild Flows, re-point CI to the Apidog CLI, and publish docs. The step-by-step guide with screenshots is how to migrate from Postman to Apidog; the cost and effort view is in what switching from Postman actually costs; and the wider list of tools is in Postman alternatives in 2026.
FAQ
Does Apidog have a collection runner? Yes, in the form of test scenarios, with unlimited runs on every plan including Free.
What replaces Postman Monitors? Scheduled tasks on the self-hosted runner, with notifications. Not multi-region.
What replaces Newman? The Apidog CLI, with generated snippets for GitHub Actions, GitLab CI, and Jenkins.
Do my Postman scripts work? Yes; pm.* pre-request and test scripts run after import.
Is there an equivalent of the Postman API Network? No. Apidog's API Hub is a catalog of your published APIs, not a public marketplace.
Checked on September 8, 2026.
