Sending requests is easy. Reading responses is where the testing happens. A junior tester checks if status is 200 and calls it a day. A senior tester inspects every tab — body, headers, cookies, time. Bugs hide in the details.
| Code | Meaning | Your Action |
|---|---|---|
| 200 OK | Request succeeded | Verify the body has correct data |
| 201 Created | Resource was created | Verify the new resource + returned ID |
| 204 No Content | Success, but nothing to return | Normal for DELETE |
| 400 Bad Request | Your request is malformed | Check your JSON body and headers |
| 401 Unauthorized | No token or expired token | Add/refresh the Authorization header |
| 403 Forbidden | Token valid but no permission | You need higher access level |
| 404 Not Found | Resource doesn't exist | Check the URL — typo? wrong ID? |
| 500 Server Error | Backend crashed | Not your fault. File a bug. |
| Response Time | Verdict | Action |
|---|---|---|
| < 200ms | Excellent | No issues |
| 200-500ms | Acceptable | Fine for most APIs |
| 500ms-1s | Slow | Worth noting. Might need optimization. |
| 1-3s | Problem | Flag it to the team. Investigate. |
| > 3s | Critical | File a performance bug immediately. |
First request to an API is always slower (cold start). Send it 3-4 times and look at the average. Don't raise a performance bug based on one slow call.
Click the Headers tab in the response panel. Most testers skip this. Don't. Some important bugs only show up in headers.
| Header | What It Tells You | Bug Signal |
|---|---|---|
| Content-Type | Format of response data | Says text/html but body is JSON? Bug. |
| X-RateLimit-Remaining | How many calls you have left | 0 means you'll get blocked on next call |
| Cache-Control | Is the response cached? | Sensitive data + cache = security issue |
| X-Powered-By | Server technology | Exposing this is a security risk |
| Set-Cookie | Server is setting a cookie | Missing HttpOnly or Secure flag = vulnerability |
After login APIs, check the Cookies tab. The server usually sets a session cookie. Verify:
A session cookie without HttpOnly flag is a security vulnerability. Attackers can steal it with XSS. If you spot this, file a security bug immediately. This is the kind of catch that makes managers notice you.
| Mode | Use When | Shortcut |
|---|---|---|
| Pretty | Default for JSON — formatted with colors | Best for reading API responses |
| Raw | Need to see the exact response bytes | Debugging encoding issues |
| Preview | API returns HTML (error pages, docs) | Renders like a browser |
| Visualize | Have a Postman visualizer script | Advanced — skip for now |
Q: What do you verify in an API response?
A: Six things. Status code — does it match expectations? Body — are all required fields present with correct values and types? No extra data — is the API leaking passwords or internal IDs? Headers — is Content-Type correct, are security headers present? Cookies — do auth cookies have HttpOnly and Secure flags? Response time — is it within SLA? Most testers stop at status code and one body field. That's not enough.
Key Point: Don't just check status code 200. Inspect body fields, data types, headers, cookies, and response time. Bugs love to hide in the tabs you skip.