Importing and Exporting Collections

A Postman collection isn't trapped inside Postman — it's just a JSON file. You can export a collection to disk, commit it to Git, share it on a wiki, and re-import it on a different machine. You can also import a wide range of formats: another Postman collection, an OpenAPI/Swagger spec, a curl command, a HAR capture, or raw HTTP. This lesson covers both directions, with an emphasis on the workflow that matters most in real teams: turning an OpenAPI spec the dev team gave you into a ready-to-test Postman collection in seconds.

Exporting a collection

Right-click any collection in the sidebar → Export. A dialog asks which format:

• Collection v2.1 (recommended) — the current standard. Compatible with Newman, every major Postman version, and most third-party tools.
• Collection v2.0 — legacy. Don't pick this unless something specifically needs it.

Click Export, choose a path, save. You'll get a file like JSONPlaceholder API Tests.postman_collection.json — a single JSON file containing every request, folder, test script, pre-request script, collection variable, and description in the collection.

Open it in a text editor. The structure is human-readable JSON — you can grep it, diff it, and (carefully) hand-edit it. The top-level shape:

{
  "info": { "name": "...", "description": "...", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/" },
  "item": [ /* requests and folders */ ],
  "variable": [ /* collection variables */ ],
  "auth": { /* collection-level auth */ },
  "event": [ /* pre-request scripts and tests */ ]
}

That's the whole collection in 100% portable form. You can email it, paste it on Slack, or commit it to your test repo.

Why export?

Three reasons that matter:

• Backups. Postman's cloud sync is reliable, but a JSON in your repo is independent of it.
• Version control. Commit the collection JSON to Git. Every change is diffable. PR reviews can show "the QA team added 3 new tests" as a normal code review.
• Sharing without a workspace. Send a JSON to a contractor who isn't in your Postman team and they can run your suite locally with Newman.

The pattern most teams settle on: collection lives in a Git repo alongside the test code. Postman is the IDE; Git is the source of truth.

Exporting environments

Environments export separately. Click the Environments tab in the sidebar → hover the environment → ⋯ menu → Export. You'll get a file like JSONPlaceholder.postman_environment.json.

Critical rule: don't commit environments containing real secrets to a public repo. Commit a sanitised version with placeholder values, and let teammates fill in their own current values locally.

Importing — the universal entry point

The Import button (top-left, next to the workspace dropdown) is a Swiss army knife. Click it. The dialog accepts:

• Files — drag a .json file in, or click to browse.
• Folder — import multiple files at once (e.g. a directory of exported collections).
• Link — paste a URL that returns JSON. Useful for OpenAPI specs hosted by your dev team.
• Raw text — paste JSON, raw HTTP, a curl command, or HAR data directly.

Postman auto-detects the format. You'll see a preview ("This looks like a Postman Collection v2.1 — Import?") with a chance to confirm.

What Postman can import

A non-exhaustive list — anything in this set works:

• Postman Collection v2.1 / v2.0 — the most common case, exporting from one workspace and importing into another.
• Postman Environment — the .postman_environment.json file.
• OpenAPI / Swagger 2.x and 3.x — a swagger.json or openapi.yaml spec.
• cURL command — paste any curl https://... line; Postman builds the request.
• HAR file — capture browser traffic as HAR, import to replay each request in Postman.
• Postman Data Dump — full workspace export.

Importing an OpenAPI spec — the QA superpower

This is the single most useful import workflow. Most modern dev teams produce an OpenAPI spec for every service. Once you have it, you can have every endpoint pre-built in Postman in 30 seconds.

The result: instead of typing 40 URLs by hand, you spend 30 seconds importing and another hour adding meaningful test assertions. The spec also encodes the parameters, status codes, and example bodies for every operation — Postman pre-fills them.

When the dev team updates the spec, re-import. Postman gives you a "Replace existing" option that preserves your tests where the operation hasn't changed.

Importing a curl command

Useful when a developer pastes a curl line in Slack as the canonical way to reproduce a bug:

curl -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer eyJhbGc..." \
  -d '{"productId": 42, "quantity": 2}'

Click Import → Raw text → paste the whole line → Continue. Postman builds the request with the URL, method, headers, and body in place. From there you can save it to a collection and start iterating.

Versioning collections with Git

A common workflow:

1. Keep your test repo in Git: tests/api/postman/JSONPlaceholder API Tests.postman_collection.json.
2. Export from Postman after meaningful changes; commit with a descriptive message.
3. Teammates git pull and re-import (Import → File → Replace existing).
4. CI checks out the file and runs it via Newman (Chapter 5) — same JSON, same tests, no Postman GUI needed in the pipeline.

For environments, commit a *.postman_environment.template.json with placeholders and add the real *.postman_environment.json to .gitignore.

⚠️ Common mistakes

• Committing environments with real secrets. Initial and current values are written to the exported JSON. Always sanitise before committing — or use a template + gitignore.
• Importing a stale OpenAPI spec. Postman won't tell you if the spec the dev team shipped is older than what's deployed. Verify the version (often in the spec's info.version field) before basing tests on it.
• Forgetting that "Replace existing" rewrites your edits. When re-importing, the Replace option keeps the collection ID but overwrites scripts and bodies you may have modified. If your edits matter, use Copy (creates a new collection) and merge changes manually.

🎯 Practice task

Move collections in and out of Postman. 20-25 minutes.

1. Export your JSONPlaceholder API Tests collection. Right-click → Export → v2.1 → save anywhere on disk.
2. Open the exported .json file in a text editor. Search for the name of one of your requests. See its method, URL, headers, and body in the JSON. Don't edit — just look.
3. Import the file back into Postman. Click Import → drop the file. Postman creates a duplicate (e.g. JSONPlaceholder API Tests Copy). Notice the round-trip is lossless.
4. Delete the imported copy.
5. Import an OpenAPI spec. Click Import → Link → paste https://petstore3.swagger.io/api/v3/openapi.json → Continue → Generate as Collection. Browse the new Swagger Petstore collection in the sidebar. Open findPetsByStatus (under pet) and read the auto-generated request. Send it.
6. Import a curl command. Click Import → Raw text → paste:

   Copy

   curl https://jsonplaceholder.typicode.com/users -H "Accept: application/json"

   Continue. Postman builds the GET request. Save it into your collection.
7. Stretch: export your JSONPlaceholder environment to disk. Open the file. Note that current values are exported too — see why you'd never commit a real secrets-laden environment to a public repo.

You can now move work in and out of Postman freely. The next lesson covers the team dimension: workspaces, real-time collaboration, and how to share collections so a teammate can pick up your work without a single file transfer.