Reading and Understanding API Responses

You've sent GETs, POSTs, PUTs, PATCHes, and DELETEs. The half of the request/response loop you've barely touched is the response itself. Postman packs a remarkable amount of information into the response panel — most testers use 20% of it and miss the bugs hiding in the other 80%. This lesson is a guided tour of every tab, every toggle, and every numeric readout, with notes on what to look for when validating an API.

The status pill, time, and size

The first thing you read is the top strip of the response panel:

• Status — the three-digit code and reason phrase, colour-coded. Green for 2xx, blue for 3xx, amber for 4xx, red for 5xx. Postman's pill matches the HTTP status code ranges you saw in the masterclass.
• Time — milliseconds from request to last byte received. Hover over it; Postman shows a breakdown (DNS lookup, TCP connect, TLS handshake, server processing, content download). When a request is mysteriously slow, that breakdown tells you whether the server is slow or your network is.
• Size — total bytes (headers + body). A response that's suddenly 10× the size of yesterday's response is a clue worth investigating: maybe a query stopped paginating, maybe the body now includes a debug payload that leaked into prod.

A useful default: if a request takes more than 1 second on a healthy network, treat it as a finding. Most user-facing APIs aim for under 300ms.

The Body tab — Pretty, Raw, Preview

The Body tab is where you read the payload. The three toggles do different things:

• Pretty — formatted, syntax-highlighted, wrapped. The view you'll use for 90% of requests. Click any field to highlight it; right-click to copy the value.
• Raw — the literal bytes the server sent, on one or two long lines. Useful when whitespace, encoding, or trailing characters matter. Some APIs are picky about trailing newlines; only Raw shows them.
• Preview — renders HTML. Most useful when an API has gone wrong and you got an HTML error page back instead of JSON: a CDN error, a load balancer's white-page, or a CAPTCHA challenge will render nicely here and give away what's actually responding.

There's also a Visualize tab for collections that ship custom visualisations, but for plain JSON APIs you can ignore it for now.

To search inside the body, focus the body panel and press Cmd/Ctrl+F. Postman opens a find bar that highlights every match — invaluable in a 3,000-line response.

The Headers tab on the response

Switch to the Headers tab on the response (not the request). You'll see something like:

Content-Type: application/json; charset=utf-8
Cache-Control: max-age=0, private, must-revalidate
ETag: "9bdfdcb7d50a0b6e4e3afeb0efeb73c5"
X-Powered-By: Express
Date: Wed, 06 May 2026 10:00:00 GMT

Headers tell you things the body never will:

• Content-Type — what kind of payload the server claims this is. Mismatch with the body (e.g. application/json but actually HTML) is a red flag.
• Cache-Control, ETag, Last-Modified — caching rules. If you're seeing stale data, these are the first headers to check.
• X-Request-Id, X-Trace-Id — correlate this request with backend logs. Copy the value; pass it to a developer when reporting a bug.
• X-RateLimit-Remaining, Retry-After — rate-limit signals. When a sequence of test requests starts failing with 429, look here.
• Set-Cookie — session cookies the server is asking your client to remember. Important for session-based auth.

A failing test that has the right body but the wrong Content-Type header is still a bug — and one that only the Headers tab will reveal.

The Cookies tab

If the response set any cookies (via Set-Cookie), they appear here. Most JSONPlaceholder responses don't, but auth flows and login endpoints often do. Postman keeps the cookie jar per-domain — once you log in, subsequent requests to the same host send the cookies back automatically.

The Test Results tab

Empty until you write tests. Once you do (Chapter 3), this tab shows pass/fail for each assertion with the count in a green or red badge — 4 / 4 passed or 2 / 4 failed. Failed assertions show the exact line that failed. We'll write our first tests in Chapter 3, Lesson 1.

Successful response vs error response

When something goes well, the response panel is calm and readable. When something has gone wrong, it tells a different story.

The difference between a fast green response and a slow red response is what API testing exists to catch. Your job is to know which side of the line a given response sits on — and to make assertions that hold the line.

Common response patterns to recognise

Real APIs don't all use the same shape. A handful of patterns turn up over and over:

• 204 No Content — successful with no body. Common after DELETE. The Body tab shows nothing; that's correct.
• Top-level wrapper — the response is { "status": "success", "data": { ... } } rather than the resource itself. Common in older APIs and some PHP/Laravel stacks. Your tests must drill response.data.field, not response.field.
• Pagination metadata — { "items": [...], "total": 247, "page": 1, "limit": 20 }. The list of resources is under items; cursors or page counts are siblings.
• Error envelope — even on a 4xx, well-designed APIs return JSON with { "error": "...", "code": "VALIDATION_FAILED", "details": [...] }. The Body tab shows the error; your tests can assert on the code field.
• HAL / JSON:API / hypermedia — responses include _links with related URLs. Less common in modern APIs but you'll see it on government and enterprise feeds.

When you first explore a new API, send a sample of each verb and look at the wrapper shape. The shape is usually consistent across every endpoint; learn it once and your tests get easier.

Saving and copying response data

• Right-click on the body → Copy Response Body — grab the whole JSON.
• The disk icon top-right of the response panel — Save Response lets you save the body to a file or save it as an "example" attached to the request (used for mocking, covered in Chapter 4).
• Save Response → Save as Example — handy when you want a known-good payload to compare future responses against.

Response history

Every request you send is logged in History in the sidebar. Click the clock icon at the top of the sidebar to see the list. Each entry stores the full request and the full response. When a test passes today and fails tomorrow, History lets you see exactly what changed in the response between the two runs.

⚠️ Common mistakes

• Asserting on the body and ignoring the status code. A 500 with the body {"data": null} looks "successful" if you only check that the response parses. The status code is your first line of defence.
• Trusting Content-Type on faith. A Content-Type: application/json header doesn't guarantee the body is valid JSON — it just claims it is. Some misconfigured servers send plain text with that header. If parsing fails, look at the Raw view.
• Ignoring the Headers tab. Rate limits, deprecation warnings (Sunset header), and trace IDs all live in headers. A passing functional test that ignores rate-limit headers will silently break the moment your test count crosses the API's quota.

🎯 Practice task

Read responses like a tester. 20-25 minutes.

1. Re-run your GET All Users request. Switch the Body view between Pretty, Raw, and Preview. Note where each is most useful.
2. Hover over the response time — read the breakdown. Which step took longest: DNS, connect, TLS, processing, or content download?
3. Switch to the Headers tab. Find and write down the values of Content-Type, Cache-Control, and Etag.
4. Trigger an error: change the URL to https://jsonplaceholder.typicode.com/users/9999 (or /no-such-thing). Send. What status code? What does the body look like? Switch to Preview to see if the body renders as anything other than JSON.
5. Send a request to a deliberately bad host: https://nonexistent.example.invalid/. Postman shows a network error rather than an HTTP response — note what the message is. This is what a "DNS failure" looks like, distinct from a server-side 5xx.
6. Use Cmd/Ctrl+F in the Pretty view to search for Lorem in a /posts response. Notice how Postman highlights every match.
7. Stretch: find a real API with pagination (try https://jsonplaceholder.typicode.com/posts?_page=1&_limit=5). Identify the wrapper shape — does the response contain a _total count? Are there Link headers pointing to the next page?

You now have a complete tour of how Postman shows you what came back from the server. That ends Chapter 1. Chapter 2 zooms out to the level of organisation: collections, environments, variables, and how to keep a hundred saved requests from descending into chaos.