Workspaces and team collaboration

Share collections and schemas with your team using SchemaClient workspaces: role-based access, invite links that need no email setup, and conflict-safe sync.

Updated

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

  1. Create a shared workspace per product or API surface — not per sprint.
  2. Keep the canonical collection and its schemas there; experiment in your personal workspace and move things over when they are worth sharing.
  3. Store environment values for shared targets (staging base URLs) in the shared collection; keep personal tokens personal.
  4. When the API has a spec, import the OpenAPI document into the shared workspace so the whole team tests against the same contract.

Frequently asked questions

How do I invite someone to a SchemaClient workspace?

Create an invite link from the workspace and send it over whatever channel you already use — Slack, email, a ticket. Whoever opens the link and signs in joins with the role the link grants. There is no email server to configure and no invitation that dies in a spam folder.

What roles does a workspace have?

Owner, Admin, Editor and Viewer. Owners control the workspace itself, Admins manage members, Editors change collections and schemas, Viewers get read-only access — enough to run requests without the risk of overwriting the shared setup.

What happens if two people edit the same workspace at once?

Sync is conflict-checked: a save built on stale data is rejected instead of silently overwriting a teammate's newer change. Refresh to pull the latest state, reapply your edit, and save again.

Are my personal collections shared with the team?

No. Your personal workspace stays yours. Only what lives in a shared workspace is visible to its members, and the workspace switcher makes it explicit which one you are working in.