Check an API response
3 minute read · API Client
Use the response to answer a concrete question: did the service return the right data, and does it behave correctly when the input changes?
- Check both the successful and failing cases
- Review scripts before running a collection
- Inspect and retain the result
- A useful three-request check
Check both the successful and failing cases
For an article-list request, confirm status, content type and a body containing the expected records. Then try the supported empty-search and invalid-input cases. A useful acceptance table is:
| Request | Expected observation |
|---|---|
| List seeded sample articles | The known IDs/titles appear, with the API's intended success status. |
| Search for a missing title | An empty result or documented not-found response, not an unrelated server error. |
| Create without a required title | A validation response that identifies the missing field. |
| Read a newly saved article | The same values after reloading the app and sending another read. |
Use your API's contract for exact status codes and fields. The table is a way to define checks, not a claim that every framework generates the same routes or JSON.
Review scripts before running a collection
Pre-request scripts can prepare values before sending; test scripts inspect results afterwards through the supported runtime. Collection and request scope determine which scripts run. Inspect imported scripts, their variable changes and any authorization context before executing them. Compatibility with common collection formats does not guarantee every third-party script extension works unchanged.
Read the script console and test-result panel as well as the HTTP status. A valid response can still fail an assertion, and a script failure can prevent the intended setup. Avoid logging bearer tokens or private response bodies merely to debug an assertion.
Inspect and retain the result
Use body, headers, cookies, timing and size together. HTML, image or PDF previews are display paths for the captured response, not proof that a whole application flow was tested. Save/export content deliberately and redact before sharing. Opening an existing result link inspects that capture rather than sending the request again. If the transport failed, record the destination class and sanitized error before retrying a potentially mutating request.
A useful three-request check
Save three requests for a development article API: create a fictional article, read it by the returned identifier, then submit an invalid article without its required title. Define what each response should contain before adding a script. Check a successful create's identifier, the read-back values and the validation error's field name.
Use the editor's supported pre-request helpers for setup and its test helpers for response checks. Keep setup and assertions small enough to understand. Inspect the collection-level script as well as the request-level script: inherited setup can alter a variable or authentication value before the request is sent. When importing a script, verify the supported helper syntax instead of assuming every extension from another client is available.
Run the saved request and inspect Tests and Console beside Body and Headers. Correct status with incorrect data is a failed test. A red test result and a transport failure need different fixes. Save the expected shape in the request's description so a teammate can understand the check even without the script. Do not log tokens, cookies or complete private response bodies for debugging.
Related guides: variables and auth, importing collections.