How do I sign up for Postman and set up my first workspace for my team?

Getting your team into Postman starts with a clean signup, then giving everyone a shared workspace where Collections, environments, and tests live together. That’s what keeps you out of the “who owns this?” cycle and gives your team a single place to develop, test, and manage APIs.

Quick Answer: Create a free Postman account, spin up a new workspace for your team, then invite collaborators and add your first Collection. From there, you can layer in environments, tests, and mocks without switching tools.

The Quick Overview

What It Is: A step‑by‑step guide to sign up for Postman and configure your first team workspace as a shared hub for API development and testing.
Who It Is For: Developers, team leads, and platform/API owners who want to move away from scattered curl commands and one‑off scripts to a shared, visible workflow.
Core Problem Solved: You stop losing track of “which version” of an API is current, and you give your team one workspace where Collections, requests, tests, and docs stay in sync.

How It Works

At a high level, getting started with Postman for your team looks like this:

Sign up and create your Postman account
Create a team‑ready workspace and configure basics
Add your first Collection and invite collaborators

Inside that flow, you’ll set the foundation for how your team will ship APIs together—using Workspaces as the shared context, Collections as the source of truth, and environments to keep credentials safe and separated across dev/stage/prod.

1. Sign up for Postman

You can start from the browser (no download required) and add the desktop client later if you prefer.

Go to Postman signup

Visit: https://identity.getpostman.com/signup
Choose how you want to sign up

You can sign up with:
- Work email and password
- Single sign‑on (if your company has it configured)
- Google or other identity providers (when available)
Verify your email
- Check your inbox for a verification email from Postman.
- Click the verification link to activate your account.
Set basic profile details

Postman will prompt you for:
- Name
- Role (e.g., backend engineer, QA, API platform)
- Organization/company name (this helps set up your Organization later)

Once you’re in, you’ll land in the Postman web experience, which is enough to create Workspaces, manage Collections, and invite teammates.

2. Create your first team workspace

Workspaces are where you centralize your API work—Collections, environments, mocks, and docs in one place. For a team, you want to create a workspace that reflects how you actually work (e.g., by product, platform, or domain), not just a personal sandbox.

Open the Workspaces view
- From the top navigation, select Workspaces.
- Click Create Workspace (usually on the top‑right or in the workspace switcher).
Name and describe the workspace

Use a name your team will recognize immediately:
- Name: Payments Platform APIs, Customer Identity Services, or Mobile Ordering Backend
- Summary/Description: Clarify scope and usage, for example:
  - “Shared workspace for Payments APIs (auth, ledger, payouts). Contains Collections for REST and WebSocket endpoints, tests, and mocks.”
Choose Workspace visibility

For a new team workspace, you typically choose:
- Team / Private to Organization: Keeps work inside your company’s Organization, with access managed via roles and groups.
- Avoid starting with a Public workspace for internal APIs—use public only when you’re intentionally publishing to external developers.
Set initial access and roles
- Assign yourself as an Admin or Workspace Owner.
- Plan who else needs Editor (for updating Collections/tests) vs Viewer (for browsing docs or running Collections).

Creating this workspace early helps you avoid ad‑hoc sharing later and sets a clear “home base” for your team.

3. Add your first Collection

Collections are where your actual requests, tests, and docs live. The workspace is the container; the Collection is the source of truth for your API usage.

Create a Collection inside your workspace
- Inside your new workspace, click New → Collection.
- Name it after the actual API or service:
  - Payments REST API, Customer Identity Service, Inventory gRPC Gateway.
Add folders for structure

Structure your API logically:
- Authentication
- Customer Accounts
- Orders
- Admin / Internal
This makes it easier for teammates to find the right request and reduces duplicate “scratch” requests floating around.
Create your first requests
- Click Add a request in the Collection.
- Set method and URL (e.g., POST https://api.example.com/v1/login).
- Use Headers and Body tabs to configure the call.
- Save the request into the appropriate folder.
Document requests as you go
- Add a short description to each request to explain:
  - When to use it
  - Required parameters
  - Expected responses
- This description becomes part of the Collection docs, so your live testing and documentation stay tied together.

4. Configure environments for dev/stage/prod

To keep secrets out of Collections and make it easy to switch between environments, you use Postman environments.

Create environments
- Click Environments in the sidebar (or New → Environment).
- Create at least:
  - Dev
  - Staging
  - Production (optional to start, but plan for it)
Add variables

For each environment, define variables for:
- base_url (e.g., https://dev.api.example.com)
- auth_token or api_key (stored as secret/protected values)
- Any environment‑specific IDs or configuration
Use variables in your requests
- Replace hard‑coded values with variables:
  - URL: {{base_url}}/v1/login
  - Headers: Authorization: Bearer {{auth_token}}
- This lets teammates switch between dev and stage without editing individual requests.

Best practice from experience: Never store raw API keys or secrets directly in Collections. Always use environment variables, and treat the Production environment as locked down with minimal editor access.

5. Invite your team to the workspace

The workspace only becomes useful when your team is actually in it—running the same Collections, updating tests, and sharing mocks.

Invite teammates from the workspace
- In your workspace, click Invite.
- Add teammates by email (prefer work emails for clarity).
- Choose roles:
  - Editor for backend engineers, QA, and SREs who will modify Collections/tests.
  - Viewer for stakeholders who only need to run requests or view docs.
Add a short workspace guide
- In the workspace description or a dedicated “README” request/folder, explain:
  - What this workspace is for
  - Which Collections are authoritative
  - How to choose the right environment (dev/stage/prod)
  - Where to request access changes or new environments
Align this workspace with your actual team structure

As your Organization grows:
- Match workspace membership to real teams (e.g., “Payments Platform Team”) rather than random ad‑hoc groups.
- Use access controls to keep internal admin APIs separate from broader product teams.

6. Add tests and mocks to keep your team unblocked

Once the core workspace is in place, layer in automation and collaboration so you aren’t relying on manual testing or waiting on backend changes.

Add tests to your Collection
- On the Tests tab of a request, add JavaScript snippets to:
  - Assert response status (e.g., 200, 201, 404)
  - Validate JSON structure
  - Check performance thresholds
- These tests run every time anyone executes the request and when Collections run in CI later.
Create mocks to unblock frontends
- From a Collection, you can create a mock server.
- Configure mocked responses for key endpoints (e.g., GET /orders/:id).
- Share the mock URL with frontend/mobile developers so they can integrate before the real backend is fully stable.
Share docs from the same Collection
- Generate documentation from your Collection.
- Share internal docs via your Private API Network or workspace links so developers always land on the live, tested Collection—not a static wiki page that drifts.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Workspaces	Centralize Collections, environments, mocks, and docs for a specific team.	Gives your team a single source of truth for API work.
Collections	Store requests, tests, and inline docs together.	Keeps documentation tied to the calls and tests you actually run.
Environments & Vars	Separate dev/stage/prod configs and secrets via variables.	Swap environments without editing requests; keep credentials safer.
Mocks & Docs	Generate mock servers and docs from the same Collection.	Let frontends build early and share accurate, always‑current docs.
Collaboration & Roles	Invite teammates and control who can view or edit workspace assets.	Align API ownership and access with your actual teams.

Ideal Use Cases

Best for teams standing up their first shared API workflow: Because it gives you a straightforward way to move curl snippets and ad‑hoc scripts into a consistent Collection, with Workspaces as the shared home for everyone.
Best for growing organizations tired of “who owns this?”: Because Workspaces, access controls, and shared Collections make it clear who maintains which API, and give you a clear path to an Organization‑wide API Catalog and Private API Network later.

Limitations & Considerations

Initial setup decisions matter: If you name Workspaces loosely (“Test” or “Random APIs”), they’re hard to scale. Spend a bit of time aligning workspace names with domains or teams.
Environment access requires care: Giving too many editors access to production environments can increase risk. Use roles and clear rules so only the right people can modify production variables.

Pricing & Plans

You can start with Postman for free and layer in team features as you grow. Pricing and features can change, so always check the current details on https://postman.com/pricing.

At a high level:

Free / Individual: Best for developers trying Postman for local work—sending requests, creating basic Collections, and experimenting in a single personal workspace.
Team / Business Plans: Best for teams needing shared Workspaces, role‑based access, higher usage limits, and Organization‑level controls across multiple Workspaces and environments.

As your API program matures, you can move from:

A few developers collaborating in a single team workspace →
Multiple domain‑aligned Workspaces under an Organization, tied into CI and eventually into an API Catalog and Private API Network.

Frequently Asked Questions

Do I need to download the Postman desktop app to set up my first workspace?

Short Answer: No. You can sign up and create your first team workspace entirely in the browser.

Details:
The browser experience is enough to:

Sign up at https://identity.getpostman.com/signup
Create and configure Workspaces
Build and organize Collections
Set up environments and variables
Invite teammates and manage roles

You can add the Postman desktop app later if you want local proxies, system‑level networking features, or prefer a desktop workflow. Both the browser and desktop app connect to the same account and Workspaces.

How should I structure Workspaces if I plan to scale to multiple teams?

Short Answer: Organize Workspaces by domain or product area and align membership with real teams, not individuals.

Details:
From running an internal API governance program, the patterns that scale are:

Domain‑based Workspaces: e.g., Payments Platform, Customer Identity, Orders & Fulfilment.
Team‑aligned access: Add only the team responsible for those APIs as editors; give adjacent teams viewer access if needed.
Shared cross‑cutting Workspaces: For platform or SRE teams running shared services, test frameworks, or organization‑wide conventions.

This makes it easier to answer “who owns this Collection?” and later to build an Organization‑wide API Catalog where each API’s ownership, specs, tests, and monitoring are visible in one place.

Summary

Signing up for Postman and setting up your first workspace for your team is less about filling out forms and more about defining a shared workflow. When you create a well‑named team workspace, add structured Collections, configure environments, and invite teammates with clear roles, you turn Postman into the place where your APIs are actually built, tested, and documented—not just another tool.

Do that once, and every new API your team ships can plug into the same pattern: Collection in the workspace, environments for dev/stage/prod, tests that run locally and in CI, and mocks and docs that keep frontends and partners unblocked.

Next Step

Get Started