Postman Workspaces

A workspace is a container that holds your collections, environments, mock servers, and monitors. Think of it as a desk in an office. One desk holds the papers for one project, and a clean desk makes work easier. Postman lets you keep as many workspaces as you need, each with its own audience and purpose.

Why Workspaces Matter

Without workspaces, every request would land in one giant pile. A freelancer who works on three client projects would mix test data, passwords, and endpoints from all three. Workspaces separate that material and control who can see it.

  YOUR POSTMAN ACCOUNT
  │
  ├── Workspace: Personal Practice
  │     └── Collections, Environments
  │
  ├── Workspace: Shop App (Team)
  │     └── Collections, Environments, Monitors
  │
  └── Workspace: Public Learning Demo
        └── Collections anyone can view

Workspace Types

Type	Who Can See It	Best For
Personal	Only you	Practice, experiments, drafts
Team	Members of your team	Shared company projects
Private	Invited people only	Sensitive internal APIs
Partner	Your team plus outside partners	Joint work with vendors or clients
Public	Anyone on the internet	Open API demos and tutorials

The available types depend on your Postman plan. Free accounts always include Personal and Public options, and paid plans add team controls.

Create Your First Workspace

1. Click the Workspaces dropdown in the top-left corner.
2. Click Create Workspace.
3. Type a clear name, such as Shop API Testing.
4. Add a short summary so teammates understand the purpose.
5. Choose the visibility type.
6. Click Create.

Postman opens the new workspace right away. The sidebar shows empty tabs for collections, environments, and more.

Move Between Workspaces

The Workspaces dropdown lists every workspace you belong to. Click a name to switch. The sidebar, history, and tabs all update to match the chosen workspace. Pin the ones you use daily so they appear at the top of the list.

Workspace Activity and Roles

Roles

Team workspaces assign roles to members. A role decides what each person can change.

• Viewer: reads collections and runs requests without editing them.
• Editor: creates and updates collections, environments, and tests.
• Admin: manages members, settings, and visibility.

Activity Feed

The workspace overview shows a feed of recent changes. You can see who edited a collection, who added a teammate, and when a monitor ran. The feed answers the common question, "Who changed this request?"

Organize Workspaces Wisely

  GOOD STRUCTURE                    WEAK STRUCTURE
  ───────────────                   ───────────────
  One workspace per product         One workspace for everything
  Clear names                       Names like "Test 1", "New"
  Roles match job duties            Everyone is an admin
  Public workspace for demos only   Secrets stored in public space

• Name workspaces after the product or project, not the person.
• Keep sensitive keys out of public workspaces at all times.
• Archive or delete workspaces that no longer serve a purpose.
• Create a separate practice workspace for learning, so experiments never touch real project data.

Real-World Example

A small company builds a mobile shopping app. The backend team owns the Shop API. The mobile team consumes it. The company creates one team workspace named Shop API. Backend developers hold the Editor role and publish collections. Mobile developers hold the Viewer role and run requests to learn the endpoints. A separate public workspace named Shop API Demo exposes a sample collection for outside developers, with safe fake data only.

Key Points

• A workspace groups related collections, environments, and tools.
• Personal, Team, Private, Partner, and Public types control visibility.
• Roles limit who can edit or only view the content.
• Separate workspaces keep practice data away from real project data.
• Public workspaces must never contain secrets.