What do you validate in an API response beyond the status code?

A 200 only tells you the server did not crash. Most real API bugs live in the body, the headers or the side effects.

1. Headers

• Content-Type is what the client expects (application/json; charset=utf-8).
• Location after a 201 points to the created resource, and that URL works.
• Caching headers (Cache-Control, ETag) are correct for the data; private data must not be publicly cacheable.
• Security headers where relevant, and CORS headers only for allowed origins.

2. Structure (schema)

Validate the shape against a JSON Schema or the OpenAPI spec: required fields present, correct types (an id that is sometimes a string and sometimes a number breaks typed clients), formats (ISO 8601 dates, UUIDs), enums, and no unexpected nulls. Schema validation catches a whole class of regressions in one assertion.

given().when().get("/orders/1001").then()
    .statusCode(200)
    .contentType(ContentType.JSON)
    .body(matchesJsonSchemaInClasspath("schemas/order.json"));

3. Values and business rules

A schema-valid response can still be wrong. Check:

• The values echo what you sent (name, quantity, currency).
• Derived values: totals, tax, discounts, status transitions.
• Defaults applied when fields were omitted.
• Lists: correct filtering, sorting, count, and no items belonging to another user.

.body("items.size()", equalTo(2))
.body("total", equalTo(59.98f))
.body("customerId", equalTo(customerId));

4. Side effects

Did the operation actually happen? Fetch the resource again with a GET, query the database in an integration environment, or verify an event was published or an email queued. A POST that returns 201 but never persists is a classic bug that response-only assertions miss.

5. Negative responses

Error bodies are part of the contract. Check the error code, message and which field failed, in the documented format (for example RFC 9457 Problem Details). Also check they do not leak stack traces, SQL or internal hostnames.

6. Non-functional checks

• A rough response-time ceiling in functional tests to catch big regressions (not a substitute for load testing).
• No sensitive data: password hashes, tokens, other users’ personal data, internal ids that should be hidden.

Keep assertions meaningful

Assert what matters for the test’s intent. Comparing the entire response to a snapshot breaks on every timestamp and new optional field; asserting only the status misses real bugs. Combine a schema check for structure with targeted value assertions for behaviour.

What interviewers look for

• A layered checklist: status, headers, schema, values, side effects.
• Understanding that schema-valid does not mean correct.
• Verifying persistence or downstream effects, not only the response.
• Checking error responses and data exposure.