The Workspace Layout
When Postman opens, the screen is divided into a left sidebar and a main working area. The sidebar lists your Collections, APIs, Environments, and History tabs, letting you navigate between saved requests without leaving the current tab. The main area splits vertically into the request builder on top, where you set the method, URL, headers, and body, and the response viewer below, which populates only after you click Send. This top-request, bottom-response layout is consistent whether you're hitting a REST endpoint, a GraphQL server, or a WebSocket connection.
Cricket analogy: It's like a broadcast screen split between the live field view on top and the scorecard ticker below — Postman's request builder is the live action you set up, and the response viewer below is the scorecard showing the result.
The Sidebar: Collections, History, and Environments
The Collections tab in the sidebar is where saved requests live, organized into folders that can nest, mirroring how an API's routes are grouped (for example, a Users folder and an Orders folder). The History tab automatically logs every request you send, even ones you never saved, which is useful for recovering a one-off request you forgot to save. The Environments panel lists the variable sets you've created — such as Local, Staging, and Production — and a dropdown in the top-right corner of the app lets you switch which environment is currently active, instantly changing what {{baseUrl}} or {{apiKey}} resolve to across every request in the workspace.
Cricket analogy: It's like a team's video analyst organizing footage into folders by opposition team and by bowler type — Postman's Collections folders organize requests by resource, the same way footage gets organized by match context.
The Request Builder Panel
The request builder is where you type the URL and pick the HTTP method from a dropdown (GET, POST, PUT, DELETE, and others). Below the URL bar sit tabs for Params, Authorization, Headers, Body, Pre-request Script, and Tests — each configuring a different part of the outgoing request. The Params tab auto-syncs with query strings typed directly into the URL, so adding ?page=2&limit=10 to the URL automatically populates a key-value table, and editing that table updates the URL in real time, keeping both views in sync.
Cricket analogy: It's like a captain's team sheet with separate fields for batting order, bowling changes, and fielding positions — Postman's tabs separate a request's URL, headers, and body into their own dedicated fields, just as organized.
The Response Viewer and Console
After clicking Send, the bottom panel switches to show the response body, with tabs for Body, Cookies, Headers, and Test Results, plus a status line reporting the HTTP status code, response time in milliseconds, and payload size. The Body tab defaults to a Pretty view that syntax-highlights and indents JSON automatically, but can be switched to Raw or Preview (which renders HTML responses like a browser would). For deeper debugging, the Postman Console, opened via View > Show Postman Console, logs the exact raw request that was sent over the wire, including headers Postman added automatically, which is essential when a request behaves differently than expected.
Cricket analogy: It's like a third-umpire review screen showing multiple camera angles and ball-tracking data before a final decision — the Postman Console shows the raw request from every angle when the visible response doesn't explain the outcome.
You can open multiple requests in separate tabs within Postman, just like browser tabs. Unsaved changes are marked with a dot on the tab, and Postman will prompt you to save before closing a tab with unsaved edits.
The Params tab and the URL bar are two views of the same data — editing one always updates the other. If you paste a URL with query parameters directly into the address bar, double-check the Params tab afterward, since a malformed query string (like an unescaped & inside a value) can silently produce an extra empty parameter.
Interface Example
// Response viewer, Pretty tab (Body)
// Status: 200 OK Time: 142 ms Size: 312 B
{
"id": 101,
"name": "Wireless Mouse",
"price": 24.99,
"inStock": true
}- Postman's layout splits into a sidebar (Collections, History, Environments) and a main area with request builder on top, response viewer below.
- Collections organize saved requests into nestable folders that mirror an API's route structure.
- The History tab logs every request sent, even unsaved ones, for later recovery.
- The environment dropdown switches which variable set (e.g., baseUrl, apiKey) is active across the whole workspace.
- Request builder tabs (Params, Authorization, Headers, Body) each configure a distinct part of the outgoing request.
- The response viewer shows status code, response time, size, and a Pretty/Raw/Preview body view.
- The Postman Console exposes the exact raw request and response, including headers Postman adds automatically.
Practice what you learned
1. Where in Postman are saved requests organized into folders?
2. What does the History tab record?
3. What happens when you edit the query string directly in the URL bar?
4. What does the Postman Console show that the standard response viewer does not?
5. What determines the value that {{baseUrl}} resolves to when a request is sent?
Was this page helpful?
You May Also Like
What Is Postman?
An introduction to Postman as an API platform for building, testing, and documenting HTTP APIs, and why it has become the standard tool for API development.
Making Your First Request
A step-by-step walkthrough of building and sending your first GET request in Postman, reading the response, and saving the request for reuse.
Request and Response Anatomy
A breakdown of the parts that make up an HTTP request (URL, headers, body) and response (status line, headers, body) as seen in Postman.