Validating Responses

Response validation techniques in ContextQA — payload validation, structure validation, status codes, and header assertions.

Who is this for? Developers and SDETs who need to assert API response payloads, status codes, headers, and full response structure in automated tests.

ContextQA provides two distinct validation modes for API responses: payload validation for asserting the value of individual fields, and structure validation for asserting the shape of the entire response object. Both are configured in the Validation section of the API testing panel.

Status code validation

Status code validation is the minimum assertion for any API test step and is configured alongside payload or structure checks.

1. Open the API testing panel (three dots on the REST API step).

2. In the Validation section, set the data type to status.

3. Choose a comparator: equal, not equal, less than, or greater than.

4. Enter the expected status code, for example 200 for a successful call or 401 for an unauthorized request.

The test step will fail if the actual status code does not satisfy the comparator condition. This catches unintended changes to authentication requirements, missing routes, or broken server-side logic.

Payload validation

Payload validation asserts that a specific field in the JSON response body matches an expected value. This is the right approach when you care about one or a few targeted fields rather than the entire response.

Setting up a payload assertion

1. Run your API request once and open Run History. Navigate to the Response Body to inspect the returned JSON.

2. Identify the JSON path to the field you want to assert. If your response is stored under the variable result, the path to an email field would be result.body.email (or the equivalent path in your response structure).

3. Return to the test step editor and open the Validation section.

4. Enter the JSON path in the JSON path field.

5. Set the comparator (for example, Equals) and the data type (for example, string for an email address).

6. Enter the expected value — the exact string, number, or boolean you expect the field to contain.

7. Click Create Update to save the validation rule.

Diagnosing failures

When a payload assertion fails, ContextQA surfaces the mismatch in Run History. The execution detail shows both the expected and actual values, letting you immediately identify whether the failure is a data change, an environment-specific issue, or a regression in the API.

To test that your assertion works in both directions, temporarily change the expected value to something incorrect, rerun, and confirm the test fails. Then restore the correct expected value.

Structure validation

Structure validation compares the entire response object against an expected object rather than a single field. Use this when you want to catch any unexpected additions, removals, or renames of fields across API versions.

Setting up a structure assertion

1. Run the API request and retrieve the response from Run History.

2. Remove dynamic fields from the response body before using it as the expected value. Fields whose values change on every call (such as timestamps, generated IDs, or session tokens) will cause the assertion to fail on every run if included. Remove them from the expected object.

3. In the Validation section of the test step, add a new assertion. Set the data type to object rather than string or number.

4. Paste the cleaned response body as the expected value.

5. Name the expected value to keep validations organized.

6. Click Create to save.

When the test executes, ContextQA compares the full response body to the expected object. Any difference in field names or structure — even if individual values differ — will cause the assertion to fail.

Payload vs. structure validation — choosing the right approach

Concern	Use
A specific field has the right value	Payload validation with a JSON path assertion
The response shape hasn't changed between deployments	Structure validation with an object assertion
Both field values and shape matter	Combine a structure assertion with one or more payload assertions in the same step

Header validation

Header assertions follow the same pattern as payload assertions. In the Validation section, reference the header using its path under the stored response variable (for example, result.headers.content-type), set the comparator and expected value, and save.

Reviewing results

All validation outcomes appear in Run History. For each test step:

• A green status indicates all assertions passed.

• A red status indicates at least one assertion failed. Open the step detail to see which assertion failed and the expected vs. actual values.

For complex response bodies, copying the raw JSON into an external notepad can help you construct the correct JSON path expressions before entering them in the validation panel.

Generate API tests from your Swagger spec in minutes. Book a Demo → — See ContextQA generate and execute REST API tests for your backend.