A Postman collection and environment import into PolyApiIDE on the free plan: requests, folders and variables move as files, and everything that needs manual work is listed below without euphemisms.
Moving between API clients rarely trips over the import itself — it trips over expectations, the assumption that everything comes along, scripts and familiar buttons included. So let us separate the two: the transport layer moves as a file, while JavaScript logic from Postman needs attention.
PolyApiIDE reads Postman Collection v2.1 and an exported environment file. Requests, folders, methods, addresses, parameters, headers and bodies come with the collection; variables come in the environment file. Both clients use the same {{var}} variable syntax, so addresses and headers keep working after the import.
If your team has scattered across tools, import is not limited to Postman: Insomnia, Hoppscotch and Thunder Client are supported, along with individual curl commands and specifications — OpenAPI in JSON and YAML, WSDL, GraphQL SDL and introspection, .proto and AsyncAPI. All of that is on the free plan; collection patching is the paid part.
Open the collection menu in the sidebar, choose Export and the Collection v2.1 format — the one marked as recommended. You get a single JSON file.
Environments are exported separately, from the Environments section, also as JSON. Without that file the variables do not travel and your requests arrive with unresolved {{var}} placeholders.
Open PolyApiIDE and load the collection first, then the environment. No sign-up is required: import works on Free. If you would rather rehearse first, ready-made sample files are on the examples page.
A Postman export does not always carry secret variable values, and access tokens are worth reissuing anyway. Walk through the environment and fill in the blanks — remember that an empty value is skipped in the hierarchy rather than overwriting the layer below.
Take one request from each folder and send it. That is quicker than proofreading the imported tree and it immediately exposes unfilled variables and forgotten auth.
| Postman item | Migrates | Comment |
|---|---|---|
| Requests, folders, methods, addresses | Yes | From the Collection v2.1 file |
| Headers, parameters, request body | Yes | Including {{var}} placeholders |
| Environment variables | Yes | As a separate environment file |
| Secret values and tokens | Partly | The export may omit them — fill them in by hand |
| Pre-request and test scripts on pm | No | The API differs; logic is rewritten on poly / pm |
| Monitors, mocks, Flows | No | Those are Postman cloud services, not part of a collection |
| History, comments, team workspaces | No | They stay in Postman |
We deliberately do not promise automatic script migration: PolyApiIDE has its own pre-request and after-response API with editor autocomplete, and a rewritten step usually ends up shorter than the original.
No. Importing a Postman collection and an environment works on Free, with no account on the site. Collection patching is the paid feature.
Target Collection v2.1 — it is the format Postman itself recommends for export. An old collection is easiest to open in Postman once and re-export as v2.1.
They do not run one for one: the function set differs. Simple assertions on status, latency, substring and JSON path usually need no code at all — they are configured as request-level QA checks.
After import the collections sit locally in the browser. Nothing leaves unless you send it — a manual export, a patch or a snapshot. There is no realtime workspace sync.
Yes. Your export files stay with you and the import does not modify the collection inside Postman, so you can run both for a while.