When a bug involves wrong data — a calculation that's off, a record that's missing, a value that's unexpected — the evidence developers need is in the API response, not the screenshot.
The frontend displays what the backend sends. If the displayed value is wrong, either the backend sent the wrong data or the frontend rendered correct data incorrectly. You can't tell which without seeing the API response. And you can't see the API response in a screenshot.
This is why API payload capture is the single most underrated component of a complete bug report.
What API Payloads Tell Developers
An API payload is the data exchanged between the frontend and backend during a user's session: the requests the browser made and the responses the server returned.
For data-driven bugs, the API response tells the developer:
- Whether the wrong data came from the server or was introduced by the frontend
- The exact value that was returned (not what was displayed, but what was received)
- Whether the response structure was unexpected (null instead of an array, missing field, wrong type)
- Whether the request itself was correct (right parameters, right endpoint, right authentication)
With the API response in the bug report, a developer can immediately determine: "The server sent the wrong data" vs. "The server sent correct data that the frontend rendered incorrectly." This distinction alone saves hours of investigation.
A Concrete Example
Without API Payloads
Bug report: "The order total shows $0.00 instead of $247.50."
Developer investigation: Logs into a test account. Creates a test order. Checks the order display. Total shows correctly. Can't reproduce. Asks QA for more information. (2 days elapsed.)
With API Payloads
Bug report: "The order total shows $0.00 instead of $247.50." + API response: {"order": {"id": 1234, "total": null, "items": [...]}}
Developer investigation: The API is returning null for total when the order has specific discount configuration. The frontend renders null as $0.00. Root cause: discount calculation service returns null instead of 0 when no discount applies to specific item types. (15-minute investigation.)
The screenshot showed the symptom. The API payload revealed the cause.
The Two Halves of a Network Payload
Request Payload
What the browser sent to the server. Relevant for bugs where the request itself was wrong:
- Filters were sent with incorrect values
- The wrong record ID was included
- Authentication token was missing or invalid
- Required parameters were omitted
Response Payload
What the server sent back. Relevant for bugs where the backend returned unexpected data:
- Field was
nullwhen a value was expected - Array was empty when it should have contained records
- Calculation returned wrong value
- Wrong status code accompanied the response
Both halves matter. The request explains what was asked for; the response explains what was provided.
How QA Teams Get API Payloads Without DevTools
Manually capturing API payloads requires opening DevTools → Network tab, finding the relevant requests, and copying the response bodies. This is technical work that most QA testers shouldn't be expected to do for every bug they report.
The practical approach is a bug reporting tool that captures network payloads automatically. SnagRelay captures all HTTP requests and responses during a user session and includes them in the bug report automatically. QA testers don't need to know DevTools exists — every report they submit includes full API payload capture.
Privacy and Security Considerations
API payloads may contain sensitive data. When implementing automatic capture, configure your tool to:
- Exclude authentication endpoints (login, token refresh)
- Sanitize fields containing passwords, credit card numbers, or PII
- Limit capture to specific endpoints relevant to your application
SnagRelay includes configurable payload filtering so sensitive data is excluded from reports automatically.
