How to Migrate Postman Collections to a New API Client (Without Losing Auth or Environments)

You've decided to move off Postman, or at least try something else for your day-to-day API work. The first practical question is what happens to the collections you've built up over months or years. The good news is most of it travels through the universally-supported Postman v2.1 export format — and the failure modes that bite people are predictable enough that you can plan around them before you migrate.

Here's the playbook, written from doing this myself more than once.

Step 1: Export your collections

In Postman, right-click any collection in the sidebar and pick Export. You get a format chooser; Collection v2.1 is the one. Save the JSON somewhere you'll find again — a postman-export/ folder on your laptop is fine for a one-off, a Git repo if you want history.

Do this for every collection you actually use. If you have a graveyard of half-finished test collections from 2022, this is a good moment to leave them behind.

Step 2: Export your environments separately

Environments are a separate export in Postman. Settings → Environments → ⋯ → Export for each one. They come out as their own JSON files (smaller — usually a list of key/value/type entries).

Critically: environment exports redact type: "secret" values. Postman replaces the secret string with an empty value on export to prevent leaking tokens through a JSON file. That's a sane default; the cost is you'll have to re-enter API keys, tokens, and OAuth2 client secrets on the other side. Make a list before you export so you know what's coming.

Step 3: Pick a destination that imports v2.1

Pretty much every serious API client supports Postman v2.1 import — Bruno, Hoppscotch, Insomnia, ShellYard, plus the long tail. The differences are in how cleanly each one imports, what they preserve, and what they translate into their own internal model.

For ShellYard specifically, it's Workspace → Collections → Import → Postman Collection (v2.1) — pick the JSON file, point it at a destination Space, and the collection lands with its folders, requests, headers, body, and inheritable auth intact.

What travels cleanly

The good news first. The following come across without fuss:

• HTTP method + URL. GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD, and custom verbs.
• Headers. Including the disabled ones (toggled off but not deleted).
• Query parameters. Same — disabled rows preserved.
• Body content. Raw (JSON, XML, plain text), form-data, x-www-form-urlencoded, GraphQL bodies. Binary bodies that point at a file path on disk will need re-attachment — the export references the path, not the bytes.
• Basic auth. Username/password pair.
• Bearer token auth. As a literal string.
• API-key auth. Header or query string placement.
• Collection structure. Folders within folders, request order.
• Variable references. {{baseUrl}}, {{authToken}}, etc. — the references travel; the values you re-create in the destination's environment.

For a request whose entire definition is "POST /v1/orders with this JSON body and a Bearer token from this env var," v2.1 import is genuinely lossless.

What needs a manual pass

These come across with caveats:

OAuth2 configurations. The config travels — token URL, client ID, scopes, grant type. The cached tokens don't (and shouldn't; tokens are short-lived secrets). After import, you'll need to fetch a fresh token in the new client. If you used Postman's "Get New Access Token" dialog with a complex configuration, double-check the imported fields against your IdP's docs — some Postman-specific fields don't have a 1:1 mapping in other clients.

Environment variables marked as secret. As above, the values are empty in the export. Have your password manager open when you do the post-import setup pass — you'll be pasting tokens for ten minutes, and it's better to do them all at once than to discover an empty {{stagingAuthToken}} mid-debugging.

Variable scoping. Postman has variables at collection level, environment level, global level, and (in some versions) data level. Most destinations have a simpler hierarchy. The translation usually flattens to "environment variables" and "collection variables." If you relied heavily on the difference between global and environment, audit those after import.

Body files. A request body that points at a local file path moves the path, not the file. Re-attach on the other side. If the file lives in a Git repo alongside the collection (a common pattern with Bruno), this is also a good moment to standardize that.

Postman v2.0 collections (the older format). Most destinations can import v2.1; some can also handle v2.0. If you have very old collections, export them as v2.1 first by opening them in current Postman and re-exporting.

What doesn't migrate

Be honest with yourself about these before you commit to the move:

Pre-request scripts and tests. Postman runs JavaScript before a request (to compute a signature, set a dynamic header, etc.) and after the response (to assert correctness, save a value to a variable). These are Postman-specific code that calls pm.request.headers.add(...) and pm.test(...). Most alternatives have some scripting layer, but the APIs don't match. Bruno has a scripting layer; ShellYard does not yet. If your collections lean heavily on pre-request scripts to sign requests or chain auth flows, you're not actually leaving Postman — you'd be rewriting your scripting layer for whichever destination you pick. Be honest about how much you depend on this before you decide.

Newman runs / CI integration. Postman's CLI runner reads collections and executes them in a pipeline. If your CI/CD calls newman run …, walking away from Postman means rewriting that step against whatever runner your new client provides. Some don't have a runner at all.

Mock servers. Postman hosts mock URLs you can point clients at. Those URLs live in Postman Cloud; they don't migrate.

Monitors. Same — Postman's scheduled-run infrastructure.

Team workspaces, comments, change history. Postman Cloud's collaboration features are the product they're charging for. They have no analog in a local-first client. If your team's API design conversations live in Postman, those conversations stay there.

Public API Network entries you forked. The fork lives in your workspace and exports fine. The connection back to the public source doesn't.

A pragmatic migration order

Don't try to do the whole house at once. The smallest workable scope:

1. Pick one collection you use daily.
2. Export it (v2.1) and its environment.
3. Import into the destination. Re-enter the secret env values.
4. Fire the most common request. Compare against Postman side by side.
5. If anything's off — variable resolution, auth-header rendering, a response that looks different — debug it now while you still have Postman to compare against.

If that one collection works end-to-end, the next ten will too. If something's broken at the JSON-body or auth-preset layer, it's better to find out on a collection you understand deeply than on one you barely remember writing.

The friction you'll feel

The single moment people regret a migration is the first time they hit a request that depended on a pre-request script they forgot they wrote. The fix is to grep your collection JSON for "script" or "exec" keys before you commit to the move, so you know exactly which requests will need attention. The export is human-readable JSON; a jq '..|.event? // empty' over the file lists every script-bearing request in a few seconds.

If you're moving to ShellYard

ShellYard's v2.1 importer brings in collections with their folder structure, request bodies, headers, query params, and the auth presets that have direct equivalents (Basic, Bearer, API key, OAuth2 client credentials). Variable references in {{var}} form resolve against the destination Space's environment after you re-key the secrets. And once a collection is in, requests can be routed through an active SSH session — useful if some of your endpoints live on internal networks the laptop can't reach, which is a friction point I cover in detail in the companion guide on testing APIs behind a bastion.

Free, local, no account needed: download it here.

For the broader picture on what an account-free API client should cover, the pillar guide for this series lays out the full requirements list — and the OAuth2 client credentials walkthrough is worth reading immediately after this one if your collections use it.