Collections stop being personal the moment a second person tests the same API. The usual workarounds — exporting JSON files into chat, screenshots of headers, "can you send me your environment?" — all rot within a week. Workspaces make the shared setup a first-class thing with an owner, members and permissions.
Personal vs shared workspaces
Every account starts with a personal workspace — private, synced across your own machines, invisible to anyone else. A shared workspace is the same structure with members: its collections and schemas are visible to everyone in it, scoped by role.
The workspace switcher in the top bar shows which one you are in. Requests, collections and schemas belong to the workspace where you created them, so work-in-progress experiments can stay personal while the team's canonical collection lives in the shared space.
Roles
| Role | What it can do |
|---|---|
| Owner | Everything, including deleting the workspace |
| Admin | Manage members and invites, edit content |
| Editor | Create and edit collections and schemas |
| Viewer | Read and run — no edits |
Give new joiners Viewer first: they can send every request in the collection without being able to break it. Promote to Editor when they need to contribute.
Invites are links, not emails
Inviting someone means creating an invite link and pasting it wherever your team already talks. Whoever opens it and signs in joins with the role attached to the link. This is deliberate: no SMTP configuration, no corporate spam filter eating the invitation, and the link works in Slack, a PR description or a ticket equally well.
Treat an active invite link like a low-grade credential — share it in team channels, not public ones, and revoke it once the team is assembled.
Conflict-safe sync
Shared state invites the classic failure: two people edit, the slower save wins, and a teammate's change vanishes without anyone noticing. SchemaClient's sync refuses that save instead — if your edit was built on a stale version of the workspace, the save is rejected, you pull the latest state, reapply, and save. Losing thirty seconds to a refresh beats silently losing a colleague's afternoon.
A workflow that holds up
- Create a shared workspace per product or API surface — not per sprint.
- Keep the canonical collection and its schemas there; experiment in your personal workspace and move things over when they are worth sharing.
- Store environment values for shared targets (staging base URLs) in the shared collection; keep personal tokens personal.
- When the API has a spec, import the OpenAPI document into the shared workspace so the whole team tests against the same contract.
Moving an existing team in
If you are arriving from a tool where collaboration became a paid tier, the order matters.
Export before you cancel anything. Some tools make workspace content read-only once a paid plan lapses. Get every collection onto disk first, including the ones you suspect are dead — you will find out later that one of them was not.
Expect secrets not to travel. Most exports deliberately omit secret-type variable values, which is correct behaviour for a file that gets emailed around. Budget time to re-enter API keys by hand, and treat it as a chance to audit which are still in use.
Rebuild the permissions deliberately. A migration is the rare moment when you can set roles properly instead of inheriting whatever accumulated. Decide who owns the workspace, who edits, and who only reads — before you send the invite link.
Verify one request per collection after importing. Import problems concentrate in auth config and in variables that pointed at something environment-specific.
The full migration walkthrough is in moving your team off Postman.
Workspaces or git?
Both solve sharing; they suit different teams.
Git-based sharing — collections as files in your repo — is excellent when everyone who needs the collection already has repo access, and it gives you review and history for free. It has no concept of roles or invitations, so bringing in QA, support or a contractor means granting repository access you may not want to grant.
Workspaces decouple collection access from code access. A support engineer can run the staging collection as a Viewer without being able to edit it, and without appearing in your repository's contributor list.
Teams that are entirely engineers often prefer git. Teams that are not, usually do not.
What to keep out of a shared workspace
Shared means shared. A few things belong in a personal workspace or a secret manager instead:
- Production credentials. If a token can act on real customer data, it should not be sitting in a workspace anyone can join by link.
- Personal access tokens tied to your own identity — audit logs will attribute a colleague's actions to you.
- Half-finished experiments. They read as canonical to whoever finds them next.