Sharing Collections with Your Team

A collection that only you can see is half-useful. A collection a whole QA team works on together — with shared environments, real-time updates, change history, and review — is where Postman starts to earn its keep on a real project. This lesson walks through Postman's sharing options, the collaboration features in team workspaces, and the conventions that keep a shared collection from becoming chaos. By the end you'll know which sharing path to choose for which scenario.

Workspaces — where sharing happens

Every Postman asset lives in a workspace. There are three kinds:

• Personal workspace. Only you can see it. The default when you create your account.
• Team workspace. All members of your Postman team can see and (depending on role) edit it.
• Public workspace. Visible to anyone on the internet. Used by API providers (Twilio, Stripe, GitHub) to publish their APIs.

A collection's visibility is determined by which workspace it lives in. Move it from a personal workspace to a team workspace and overnight everyone has it.

To create a team workspace: Workspace dropdown (top-left) → Create Workspace → Type: Team. Name it (e.g. "QA — Acme Shop"), invite teammates by email. Free Postman teams support a small number of seats; paid plans add more.

Four ways to share a collection

The right approach depends on who needs to see it and how often.

1. Team workspace

The everyday answer for any team where multiple people touch the same API. Move the collection to a team workspace; everyone sees it and edits propagate live.

• Right-click the collection → Move → pick the team workspace.
• Or Share → Move to Workspace → pick the team workspace.

Once shared, edits show up for teammates within a second or two. Conflict detection warns if two people edit the same request at the same time.

2. Export + Git

The version-control-friendly answer. Useful when:

• Your team is small or doesn't want a paid Postman plan.
• The collection lives next to test code in a Git repo.
• You want PR-style review on every change.
• CI runs the collection (Newman doesn't need a Postman account).

Export the collection (covered in the previous lesson), commit the JSON, teammates pull and re-import. Slower feedback than a team workspace but every change is in your repo's history.

3. Share link

Right-click the collection → Share → Get Public Link (requires a Postman account). You get a URL anyone can open in their Postman app to fork the collection into their own workspace. Good for one-off sharing — e.g. with a contractor outside your team — but every fork is a snapshot, not a live link.

4. Run in Postman button

Embed an HTML button on a wiki, README, or blog post. Visitors click it and the collection imports straight into their Postman. Useful when you publish public docs (or open-source an API) and want zero-friction onboarding.

<a href="https://app.getpostman.com/run-collection/<id>"
   ><img src="https://run.pstmn.io/button.svg" alt="Run in Postman"></a>

Generated automatically when you click Share → Run in Postman.

Personal vs team — what changes

For a real QA team, the team workspace is almost always worth the seat cost — the alternative is everybody manually keeping JSON files in sync, which fails reliably under any project pressure.

Collaboration features that matter

Once your team is in a shared workspace, a few features change how you work day-to-day.

Forks

Right-click a collection → Create a fork. You get your own copy under a fork name (JSONPlaceholder API Tests — alice's fork). Edit freely; the parent stays intact. Useful when:

• You're prototyping a refactor of test scripts.
• You want to try a risky change without breaking the team's running suite.
• You're handing a contractor a starting point they can edit without affecting yours.

Pull requests

Once your fork has changes you want to bring back to the parent, click Create pull request. Teammates with edit access on the parent see the diff (request bodies, scripts, headers — all diffable) and can approve, request changes, or merge. The flow is the same as Git PRs; the unit is requests instead of files.

This is genuinely how serious teams maintain large collections — it adds review where there used to be just "save and hope."

Activity feed

Open the collection → Activity tab. Every change — edit, fork, PR, comment — is logged with a timestamp and author. When a request that worked yesterday fails today, the activity feed often answers "what changed?" before you've finished asking the question.

Comments

Right-click any request → Comment. The comment appears in a sidebar; teammates can reply. Useful for:

• "This endpoint sometimes returns 502, raised ticket SUPP-1024."
• "Don't run this in prod; it actually charges the card."
• "Why is the auth header hardcoded? Should it be {{authToken}}?"

Comments are tied to the request, not the workspace, so they travel if the collection moves.

Roles

Free team plans give you Editor and Viewer roles. Paid plans add Admin and granular permissions per workspace and collection. The simple rule: non-developers (PM, support) get Viewer; QA/dev who write tests get Editor; one or two leads get Admin.

Conventions that keep shared collections sane

A collection shared across five people without conventions becomes a tip in three weeks. A few that hold up:

• One collection per service. Don't mix multiple unrelated APIs.
• Folders by resource or flow — pick one (covered in Lesson 1).
• Auth at the collection level, not on individual requests.
• No hardcoded URLs or tokens — environments only.
• Names are verb-first and descriptive — GET All Users, not users-get-list.
• Descriptions on requests that need them — auth behaviour, side effects, rate limits.
• Tests live in the collection, not in a separate file — easier to keep current.
• Source of truth is the team workspace OR Git — pick one and route changes through it.

These conventions are mostly self-enforcing once written down. Drop them in the collection's description so new joiners read them on day one.

⚠️ Common mistakes

• Treating a personal workspace as a team workspace. Sharing your account login is not the same as a team workspace. It loses change history, conflict detection, and fork/PR — all the features that justify Postman in a team.
• Editing the parent collection directly when you should fork. Risky changes go in a fork; merge after review. Editing the live shared collection is fine for tiny tweaks but the wrong default for anything load-bearing.
• Letting environments drift. "It works for me" usually means a teammate has a current value you don't. Document required environment variables in the collection description, and use the Initial-value/Current-value distinction from the previous lesson.

🎯 Practice task

Practise team collaboration. 20-25 minutes.

1. If you're working alone, create a second personal workspace called QA Course Practice — Sandbox. Move (or fork) your JSONPlaceholder API Tests collection into it. This gives you two workspaces to practise moving between.
2. Fork your collection. Right-click → Create a fork → name it <yourname>-fork. Open a request in the fork and change something (e.g. the response-time threshold from 2000ms to 1500ms). Save.
3. Create a pull request from the fork back to the original. Read the diff Postman shows. Merge it.
4. Open the Activity tab on the collection. See your fork, edit, and merge events logged with timestamps.
5. Right-click any request → Comment. Add a note like "Add negative-case test for invalid IDs." Notice the comment is attached to the request.
6. Click Share → Get Public Link. Open the link in a private browser window — it routes to a Postman page where someone could fork the collection. Don't keep the link enabled long.
7. Stretch: if you have a teammate or friend with a Postman account, invite them to a free team workspace, move the collection in, and edit a request from each side at the same time. Watch the live updates and the conflict warning.

You can now share work without losing your mind. That ends Chapter 2 — your collection is named, organised, parameterised, exportable, and shareable. Chapter 3 turns Postman from a request-builder into a test tool: writing assertions, validating bodies, and chaining variables across requests.