Migrating from Postman
1. Export from Postman
Section titled “1. Export from Postman”In Postman: Collection ▸ … ▸ Export ▸ Collection v2.1. Do the same for your environments.
2. Import into Restorm
Section titled “2. Import into Restorm”File ▸ Import (Ctrl+I) then the JSON file. Restorm detects the format on its
own.
Details: Importing a Postman collection.
What carries over automatically
Section titled “What carries over automatically”| Postman | Restorm |
|---|---|
| Folders | Folders, at the same depth |
| HTTP requests | HTTP requests |
| GraphQL requests | GraphQL requests (not HTTP requests) |
| raw, formdata, urlencoded, file, graphql bodies | The matching body type |
| Collection variables | An environment’s variables |
| Descriptions | Notes and API documentation |
| Sample responses | API documentation |
| Pre-request and test scripts | A runnable scenario, with the pm.* layer |
What needs adjusting
Section titled “What needs adjusting”Authentication
Section titled “Authentication”Postman’s authentication blocks are documented (sensitive values masked) but not converted into executable credentials.
Recreate an authentication request: it is a
five-minute job, and you gain automatic token renewal and the retry on 401, which
Postman does not do on its own.
Environments
Section titled “Environments”Export them from Postman and recreate them in an environment folder.
While you are at it, make use of sub-environments: where Postman imposes one flat environment per target, Restorm lets you have a common base with overrides per customer or per region.
Runners and Newman
Section titled “Runners and Newman”This is the most rewarding replacement. A scenario does what a runner does, only better:
- the flow is visible instead of being an implicit collection order;
- branches, loops and retries are boxes, not
pm.setNextRequest; - running in CI is built in, with clean exit codes — see Headless execution and CI.
How the concepts map
Section titled “How the concepts map”| Postman | Restorm |
|---|---|
| Workspace | A .restorm project, version-controlled in git |
| Collection | A folder or an environment folder |
| Environment | An environment inside an environment folder |
| Globals | A root environment, inherited by its children |
| Pre-request / Test script | A scenario, or a code action |
| Collection Runner | A scenario |
| Newman | restorm --run --headless |
| Mock Server | Server mode, locally |
| Monitors | A Timer action, or a scheduled job in your CI |
| Postman Console | The console |
{{$random…}} dynamic variables | The same ones, plus 116 helpers — see the reference |
The fundamental difference
Section titled “The fundamental difference”Your requests become files in your repository. They follow the same review cycle as your code, their history is the git history, and the access rights are your forge’s.
No hosted workspace to administer, and no API data on a third-party service. See
.restorm projects and files.
And what Postman has that Restorm does not
Section titled “And what Postman has that Restorm does not”To be honest: Restorm has no hosted collaborative workspace, no public API portal, no inline comments on requests, and no hosted monitoring. If your organisation relies on those, they have no direct equivalent — sharing goes through git.