How Can You Check a JSON API Response from a Terminal?
From the earlier reference collection. Read the current software blog.
Inspect the HTTP response and parse the body as JSON before relying on fields or values returned by an endpoint.
Check the response separately from the body
A response body that looks like JSON does not establish that the request succeeded. A server may return a JSON error object with an unsuccessful status, or an HTML page despite a client expecting JSON. Use a command that exposes the HTTP status and headers as well as the body. For example, curl --include --fail-with-body URL shows headers and retains the error body for inspection while signaling an unsuccessful HTTP status through its exit code.
Be aware that combining headers and a body in one stream makes it awkward to feed directly to a JSON parser. For a clean workflow, save the body to a temporary file and write status information to a separate file or terminal.
Inspect useful headers
Look at the final status after redirects and the Content-Type header. An application/json media type is a useful expectation, but some APIs use a vendor-specific JSON type; conversely, headers can be misconfigured. Content type is a consistency check, not a substitute for parsing the actual body.
You may also inspect cache or version headers if they matter to your application. Do not print authorization headers or secrets while debugging. If a request requires credentials, pass them through a protected mechanism rather than placing them in a command that may be saved in shell history or process listings.
Parse with a JSON-aware tool
Use a parser to establish that the body is valid JSON. With Python, python -m json.tool response.json formats valid JSON and exits with an error for malformed input. With jq, jq . response.json provides a similar quick check and can select a field, for example jq -r '.status' response.json. A successful parse only establishes syntax; it does not prove the response has the fields or meanings your program requires.
For an expected object, inspect both shape and values. Check that an ID is present and that a numeric reading is actually numeric, rather than accepting any parseable JSON value. Handle null, missing fields, and arrays explicitly.
Make the check repeatable
Record the endpoint, request parameters that are safe to retain, response status, and parser outcome. Test a normal response and representative error responses so later changes do not cause an error object to be processed as a successful result. Keep the body and metadata separate when building scripts, and return failure when either the HTTP or schema check fails.
This two-part check—transport status followed by structured-body validation—catches different classes of problems. It is a small terminal routine that can prevent a plausible-looking response from silently entering a larger data pipeline.