Migration
Migrate from Postman without rebuilding your tests by hand
Routebase turns a Postman collection into an OpenAPI specification with a preview before anything is written, generates test cases from that spec, and lets an agent rebuild the assertions.
14-day Pro trial — no credit card required.
Most teams migrate from Postman later than they want to, because the estimate reads as weeks of retyping requests and rewriting test scripts with no feature at the end. Routebase reads a Postman collection or an Insomnia export natively and turns it into an OpenAPI specification in minutes. A preview counts the endpoints, folders and schemas it would create and lists the warnings with their location, so you read the result before you confirm it. Request bodies and saved responses become schemas, which the import marks as inferred from examples so nobody mistakes a first draft for a finished contract. From the specification, one click generates a test case per endpoint, and an agent working over MCP rebuilds the assertions your scripts used to carry. The specification exports back to Postman, Insomnia, YAML or JSON at any time.
What a Postman collection becomes
The importer maps the collection onto the structure your team will keep, and it reports what it inferred rather than pretending it was declared.
- Folders become folders in the specification, request names become endpoint summaries
- Path segments like :id and {{orderId}} become path parameters, query strings and headers become parameters
- JSON request bodies and saved responses become schemas, with formats such as uuid, email and date-time recognised
- Bearer, Basic and API key auth become security schemes, at collection level and per request
- Duplicate requests merge into one endpoint, and the preview says which
What the import cannot know, and says so
A collection records calls that worked, so a few things have no place in a contract, and the preview names the ones it recognises before anything is written.
- Pre-request and test scripts stay behind, because assertions were never part of the contract
- Collection variables beyond the base URL are not imported, so secrets are never copied
- A schema inferred from one example marks every present field as required and cannot see enums
- OAuth2 and other advanced auth flows are set up in the environment afterwards, not carried over
From collection to test suite
The tests are the part everyone dreads, and they come back in two steps, one click for the cases and an agent for the assertions.
- Import from API Spec creates a test case per endpoint with assertions pre-filled, from the Starter plan
- pm.test checks become status, jsonPath and header assertions, pm.environment.set becomes a response extraction
- Chained requests become scenarios, shared logic becomes a reusable script snippet
- An agent connected over MCP imports, corrects the inferred schemas, rebuilds the assertions and runs the suite
Insomnia, and the way back out
Insomnia Export v4 is read natively, and every frozen version of the specification exports again, so the door swings both ways.
- Request groups become folders, JSON bodies become schemas, Bearer and Basic auth become security schemes
- Insomnia exports carry no saved responses and no environments, so responses and variables are added in Routebase
- Export a frozen version as Postman, Insomnia, YAML or JSON, with requests and examples but never credentials
Frequently asked questions
How long does it take to migrate from Postman?
That depends on the collection, and we won't invent a number for yours. Start with a dozen requests as a pilot, run the preview, read the warnings and let the first suite run against your API. That afternoon tells you more than an estimate.
Which Postman and Insomnia versions can I import?
Postman Collection v2.1 and Insomnia Export v4, both as JSON files, through the specification wizard inside a project. The newer Insomnia v5 format is not supported yet, so export as v4 first. The dashboard import dialog reads OpenAPI only.
What happens to my pm.test scripts?
They are not imported, because assertions were never part of the OpenAPI contract, but each kind has a destination. Status and body checks become declarative assertions, token stashing becomes a response extraction, and chained requests become scenarios. The walkthrough in our blog shows the mapping request by request.
What about environments and variables?
The base URL variable becomes the server URL of the specification, and other collection variables and Insomnia environments are not imported, which the preview says in a warning. You recreate the environments in Routebase, and secrets are entered there rather than copied from a file. An agent can import variables from a .env or JSON file with a preview of the keys that look like secrets.
Do I need an OpenAPI specification before I migrate?
No. The collection becomes the specification, and Routebase builds the OpenAPI as you go. If you already have a specification, import it directly and use the collection only for the requests it knows that the specification does not.
Can I export the specification again?
Yes. Every frozen version exports as OpenAPI YAML or JSON, as a Postman collection or as an Insomnia export, with your requests, examples and descriptions. Credentials are never part of an export, so the file is safe to hand to a consumer.
One living spec
What the spec drives afterwards
Change the spec — everything on this page updates with it.
Ready to ship on it?
Routebase is live. Design your API once — docs, mocks, tests, and monitoring all follow from the same source.
14-day Pro trial — no credit card required.