Still deciding? See Tetiva as a Postman alternative first, or download Tetiva and try the import on a real collection.
Moving over takes two actions: export your Postman collection as Collection v2.1, then import that file into Tetiva. Folder structure, requests, headers, bodies and auth come across, and environments come across as separate files. Scripts, collection variables and anything tied to the Postman cloud do not — you rewrite those by hand, and the checklist below says exactly what to look at.
Step 1. Export from Postman#
- In the collection menu choose Export and the Collection v2.1 format. Save the
.json. - Export environments separately — one file per environment.
Format v2.0 is rejected: the import stops with unsupported schema, only Postman Collection v2.1 is supported. If someone handed you a file and you are not sure, open it and check info.schema — it must contain v2.1.
Step 2. Import into Tetiva#
- Into the sidebar root — the down-arrow button in the collections header, tooltip Import Postman Collection.
- Inside an existing collection — right-click it and choose Import Postman Collection. The imported tree lands inside that collection.
- Pick the
.json. A toast reports the result: "Imported: 4 folders, 27 requests". - Environments — the environment selector in the request bar → Manage Environments… → the import button (tooltip Import Postman Environment).
The Postman collection itself becomes a normal Tetiva collection and its folders become nested collections. Nesting depth is not capped.
Concept mapping#
| Postman | Tetiva |
|---|---|
| Collection | Top-level collection: name, description, auth |
| Folder | Nested collection: name, description, auth |
| Request | Request: name, method, URL, headers, body, auth |
| Disabled header | Header with its checkbox off — the value is kept |
| Auth: Bearer, Basic, API Key | Same types; API Key keeps its name and value, but not its location — the key always lands in the header |
| Auth: OAuth 2.0, AWS, Digest, NTLM, others | No Auth — configure it again |
| Body: raw + JSON | JSON body |
| Body: raw + XML or HTML | XML body |
| Body: raw with no language | Raw body |
| Body: form-data | Form body; file fields must be re-picked |
| Body: GraphQL | A GraphQL request — POST, with query and variables in place |
| Body: x-www-form-urlencoded | Empty — retype it in the Body tab |
| Body: binary | Empty — choose the file again |
| Environment (separate file) | Environment; secret-typed variables stay secret |
| A method outside GET…HEAD | GET |
What does not carry over#
| Item | What to do |
|---|---|
| Pre-request and Tests scripts, at every level | Rewrite them — see the pm.* table below |
| Collection variables and globals | Move them into an environment |
| Per-request descriptions | Collections and folders keep theirs; requests have nowhere to store one |
Path variable values (:id) | The placeholder stays in the URL — substitute an environment variable |
| Examples, mock servers, monitors, Runner, Flows | No equivalent |
Check these after the import#
Inherited auth. In Postman a request with no auth block of its own uses the collection's auth. On import such a request lands as No Auth, so the collection token is not applied. Open the Auth tab on those requests and pick Inherit — from there the lookup walks up the collection tree, see Authentication.
API Key placement. The importer always puts the key into the header, even when Postman had it in the query string. Check the Add to switch on the Auth tab of those requests.
Urlencoded and binary bodies. Their content is not carried over: rebuild them in the Body tab.
Environment variables. Every value in the file is imported, including the ones you had disabled in Postman, and all of them arrive enabled. Walk the list and uncheck what you do not need.
Secrets. Secret-typed variables stay secret in Tetiva, but the Postman export file holds their values in plain text — do not leave it in a shared folder.
Scripting: pm.* coverage#
Tetiva scripts run on the goja engine — JavaScript, but neither Node nor a browser. The pm object is implemented partially, so Postman tests almost always need edits. The full reference lives in Scripting.
| Call | Status |
|---|---|
pm.environment.get(key), set(key, value), unset(key) | Supported |
pm.request.method, pm.request.url, pm.request.protocol | Supported; url is a string, not an object |
pm.request.headers.upsert({ key, value }), pm.request.headers.remove(key) | Supported; headers has no other methods |
pm.response.code, pm.response.statusText, pm.response.text(), pm.response.json() | Supported in post-response scripts; statusText is gRPC only — undefined for HTTP and GraphQL |
pm.response.status | Exists, but it aliases the code — a number, not Postman's "OK" |
pm.test(name, fn) | Supported; results show up in the Tests tab |
console.log, info, warn, error | Supported; output is collected per run |
pm.expect(...), pm.response.to.have.status(...) | Not available — assert with throw |
pm.globals, pm.collectionVariables, pm.variables | Not available — use pm.environment |
pm.sendRequest(), pm.setNextRequest() | Not available |
require(), file or network access from a script | Not available — the sandbox is closed and a run is cut off after 5 seconds |
A typical test is three lines either way. Postman:
pm.test("status is 200", function () {
pm.response.to.have.status(200);
});
pm.environment.set("token", pm.response.json().access_token);Tetiva:
pm.test('status is 200', () => {
if (pm.response.code !== 200) throw new Error('got ' + pm.response.code)
})
pm.environment.set('token', pm.response.json().access_token)A test fails when its function throws, and the error message is shown next to the test name in the Tests tab.
Exporting back to Postman#
The door swings both ways: right-click a collection and choose Export as Postman to write a v2.1 file named <collection>.postman_collection.json. Environments export from Manage Environments… with Export as Postman.
Two limits apply. Scripts are not written into the export, and gRPC and WebSocket requests have no place in the Postman format — name, address and body survive, while the service, method, .proto path and metadata do not. More detail in Import and export.