Postman’s OpenAPI import vs Portman
Postman can generate a collection from an OpenAPI spec with folders, requests and response examples, and keep it in sync; tests are added by hand or with Agent Mode. Portman builds on the same converter (openapi-to-postman) and Newman, and adds generated contract, content and variation tests from a config file in CI. Use Postman’s import for exploring and documenting an API, and Portman when you want the tests generated and run from the spec.
About Postman
Postman is an API platform. It can generate a collection from an OpenAPI, AsyncAPI or Smithy spec, sync collections with OpenAPI 2.0, 3.0 and 3.1 specs, lint specs against governance rules with the Postman CLI (governance rules on Enterprise plans), and run collections with the Postman CLI or Newman. Postman also maintains an open-source MCP server (Apache 2.0) for AI agents. Portman uses Postman’s open-source openapi-to-postman converter and Newman under the hood, so the two are complementary.
Feature comparison
| Capability | Portman | Postman |
|---|---|---|
| Approach | CLI: spec plus config file in, collection with tests out | App and CLI: generate a collection from a spec in Postman |
| Spec input | OpenAPI 3.0 and 3.1 | OpenAPI (2.0, 3.0, 3.1), AsyncAPI, Smithy |
| Output | Postman collection with test scripts | Collection with folders, requests and response examples |
| Test generation | Contract, content, variation and integration tests from config | Manual scripts, or suggested by Agent Mode |
| Response schema validation | Yes — JSON Schema test injected per response | Written by hand (pm.response.to.have.jsonSchema) |
| Fuzzing and negative testing | Partial — rule-based fuzzing and variation tests | Not generated from the spec |
| Stateful tests and chaining | Configured — assignVariables and overwrites | Scripts setting variables by hand |
| Spec sync | Regenerate from the spec on each run; --syncPostman uploads | Built-in sync between spec and collection |
| CI usage and exit codes | Exit code 1 on any failed assertion | Postman CLI or Newman run collections in CI |
| Spec linting / governance | No | Yes — postman spec lint (governance rules on Enterprise) |
| MCP / AI agent support | No MCP server; Apideck agent skill available | Yes — Postman MCP server; Agent Mode in the app |
| License and status | Apache 2.0, maintained | Commercial platform; openapi-to-postman and Newman are Apache 2.0 |
Choose Postman if…
- You want to explore, document and share an API in the Postman app, and tests are added by people as needed.
- You need governance linting of specs across a team.
- You want the collection kept in sync with a spec managed inside Postman.
Choose Portman if…
- You want contract tests generated for every operation from the spec instead of writing them per request.
- You want the test suite defined in a versioned config file and regenerated in CI whenever the spec changes.
- You want variation and fuzzing requests for error responses without hand-building them.
Using them together
Portman is built on openapi-to-postman and Newman, so its output is a regular Postman collection. Generate and run it in CI with Portman, then upload it to your Postman workspace with --syncPostman so the team can open, run and debug the same tests in Postman.