Postman has always been the platform where API development comes together — from firing off test requests to validating response contracts. With the latest Postman release, that scope expands significantly. Git integration, Local Mocks, an embedded terminal, multi-protocol support in a single collection, and an AI assistant with repository context — these aren’t add-ons to the platform. They’re the building blocks of a full local development environment that sits alongside your code the way a terminal or an editor does.
This post walks through each of those features hands-on, using the Intergalactic Banking API — a REST API for managing accounts and interplanetary credit transfers — as the running example. By the end, you’ll have set up a Git-backed workspace, run Local Mocks offline, used Agent Mode to generate tests, and run a multi-protocol collection in CI.
What you’ll need
- Postman — download here
- Git installed locally (
git --version to check)
- A GitHub account (or any Git host) for the Local View walkthrough
- Postman CLI for the CI section — install with:
curl -o- "https://dl-cli.pstmn.io/install.sh" | sh
Fork the sample workspace
All the examples in this post use the Intergalactic Banking API public workspace. Fork it into your own account to follow along:
- Open the workspace link above
- Click Fork in the top-right
- Choose a name and the personal workspace to fork into
- Click Fork Collection
You’ll now have the collection, environment, and OpenAPI spec in your own workspace, ready to use.
The Unified Workbench: one place for everything
The Unified Workbench — collections, environments, Spec Hub, and mocks in one sidebar.
The first thing you’ll notice in new Postman platform is the Unified Workbench. Collections, environments, API specs, mock servers, and flows all live in a single customizable sidebar — no more switching between panels mid-request.
To see it in action with the forked workspace:
- Open Postman and navigate to your forked workspace
- In the sidebar, you should see Collections, Environments, and APIs listed together
- Click APIs in the sidebar — this opens Spec Hub, where the OpenAPI spec for the Intergalactic Banking API lives
- Pin the spec tab and open the collection side-by-side — you can now cross-reference the spec while building requests without losing context
That last step used to require jumping between browser tabs or separate windows. It’s a split view.
Cloud View and Local View: setting up Git integration
The Cloud View / Local View toggle — select Local View to work with a Git-backed workspace.
Local View is where Postman’s local-first architecture becomes concrete. Your Postman workspace is backed by a local directory and a connected Git repository — collections, environments, and specs are files on disk, not just cloud state.
Here’s how to connect your forked workspace to Git:
- In your workspace header, click Connect to Git
- Choose GitHub (or your preferred Git host) and authenticate
- Create a new repository (e.g.,
intergalactic-banking-api-workspace) or connect to an existing one
- Postman will push the initial workspace files to the repo — you’ll see a branch name appear in the header
Once connected, switch to Local View using the toggle in the top-left of the workspace. Your files are now on disk.
Try making a change and committing it:
- Open the
POST /transfers request in the collection and add a new example response
- Open the embedded terminal (bottom of the Workbench) and run:
git status
You’ll see the collection file listed as modified. Stage and commit it:
git checkout -b feature/add-transfer-example
git add .
git commit -m "Add example response for POST /transfers"
git push origin feature/add-transfer-example
- Open a pull request on GitHub — the collection diff will show exactly which request changed and how
Reviewers can now see the contract change and the implementation change in the same PR review.
Local Mocks: offline iteration without dependencies
Local Mocks live right in the Workbench sidebar — create, configure, and run them without leaving the collection view.
Rather than pointing every request at a live server while you’re building, Local Mocks let you define the responses you expect and iterate entirely offline — no staging environment, no flaky upstream dependencies.
The easiest path: let Agent Mode build the mock
Open Agent Mode and paste this prompt:
Create a local mock for this collection. For each endpoint, generate
realistic response bodies that match the OpenAPI spec in Spec Hub.
Include at least one happy path and one error response per endpoint.
Agent Mode generates the full mock configuration — for the Intergalactic Banking API that covers all five endpoints (/health, /auth, /accounts, /accounts/{id}, /transactions/{id}) with realistic response bodies matched to the OpenAPI spec.
Review the responses, adjust any values you want, and click Start Mock — the server starts on http://localhost:3001.
Set your environment variable to point at it:
base_url = http://localhost:3001
Every request in your collection now resolves against the mock. No live server needed.
Running the mock in CI:
Local Mocks start automatically when you run the collection with the Postman CLI:
# .github/workflows/api-tests.yml
- name: Run collection with local mock
run: |
postman collection run "${{ secrets.COLLECTION_ID }}" \
--environment "${{ secrets.ENVIRONMENT_ID }}" \
--bail
The mock that ran on your machine runs identically in the pipeline — no extra configuration needed.
The embedded terminal: Git without context switching
The embedded terminal — run Git commands, the Postman CLI, or debug scripts without switching to a separate window.
The terminal panel at the bottom of the Workbench is where the Git workflow happens without leaving Postman.
# Check what's changed in your workspace
git status
# See recent commits
git log --oneline -5
# Run your collection and see results inline
postman collection run $COLLECTION_ID --environment $ENVIRONMENT_ID
A real debugging scenario: Say a test fails in CI with a schema mismatch on GET /accounts. Here’s the workflow entirely inside Postman:
- Open the terminal and run
git log --oneline -5 to see recent changes
- Spot the commit that modified the spec:
a3f9c12 Update /accounts response schema
- Run
git show a3f9c12 -- openapi.yaml to see exactly what changed
- Fix the drift in Spec Hub, update the test, commit — done
Every context switch you avoid is cognitive overhead you keep.
Multi-protocol support: one collection for the full system
One collection, all protocols — REST, WebSocket, and gRPC requests run together in the Collection Runner.
In Postman, REST, WebSocket, and gRPC requests can all live in the same collection. Here’s how to add a WebSocket request alongside your existing REST requests:
- In your collection, click + Add request
- Change the request type dropdown from
GET to WebSocket
- Enter the URL:
wss://api.intergalactic.bank/v1/status
- In the Messages tab, add a subscribe message:
{
"action": "subscribe",
"transfer_id": "{{transfer_id}}"
}
- Save the request inside the same collection folder as your REST requests
When you run the collection with the Collection Runner, it executes REST, WebSocket, and gRPC requests in sequence. For a transfer that touches a REST endpoint, triggers a WebSocket event, and gets logged through gRPC — this is the only way to test the actual end-to-end flow in a single run.
Putting it together
Here’s the full local development loop:
- Fork the workspace and connect it to Git (Local View)
- Branch for your feature in the embedded terminal:
git checkout -b feature/new-endpoint
- Build the new request in the Workbench, cross-referencing the spec in Spec Hub
- Mock any dependencies with Local Mocks so you’re not blocked by other teams
- Commit the collection change alongside your code change
- Run the full collection in CI with the Postman CLI — mocks start automatically
Your workspace is a directory. Your changes are commits. Your mocks run locally. Your tests run in CI without reconfiguration. The development loop closes inside Postman rather than requiring five different tools.
Get started
The post Postman as a Local Development Environment appeared first on Postman Blog.
Log in
