3.2 JSONPath Runtime Extractions & Body Assertions

How to extract dynamic tokens using JSONPath and assert on response body structures.

Example: a booking lifecycle

This case runs against restful-booker, a public practice API. It creates a booking, reads it back, updates it, deletes it, and confirms it is gone. Each request captures values (the auth token and the booking id) and passes them to the next, and each response is checked with status and JSONPath assertions.

Running the suite produces one report. All eight cases pass.

One Step, Two Jobs: Extracting and Asserting

An API Request step doesn’t hand extraction and assertion off to separate step types – both live as sub-lists on the same step, in the Vars and Assertions tabs from 4.1. The Vars tab holds variable captures: give a capture a variable name and a source (JSON_PATH, XPATH, HEADER, STATUS_CODE, or BODY_RAW) and an expression, and CertiQA pulls that value out of the response the instant it arrives, ready for {{ that variable }} to be referenced by any step later in the case. A capture also takes an optional default value, used only when the expression doesn’t resolve – so a step reaching for {{ orderId }} two steps later gets a safe fallback instead of an undefined-variable failure when, say, a response occasionally omits the field on a retry.

JSONPath expressions use the familiar $.field.nested syntax – $.data.orderId, items[0].id, results[*].status – resolved against the parsed response body. The Assertions tab is the same idea aimed at pass/fail instead of variable capture: each rule names a target, an operator, and an expected value, and every rule on a step must pass for the step itself to pass.

Assertion Target	Checks	Typical Operators
STATUS_CODE	The numeric HTTP response status.	EQUALS, GREATER_THAN, LESS_THAN
JSON_PATH	A value at a JSONPath expression, e.g. $.status.	EQUALS, CONTAINS, EXISTS, NOT_EXISTS
HEADER	A specific response header value.	EQUALS, CONTAINS
RESPONSE_TIME	Round-trip latency in milliseconds.	LESS_THAN
JSON_SCHEMA	The entire response body validated against a JSON Schema document.	SCHEMA_VALID

When the Body Isn’t JSON

• A JSON_PATH capture or assertion against a response that fails to parse as JSON doesn’t crash the run – the capture is skipped in favor of its default value, and the assertion fails with an explicit “response is not JSON” message rather than a raw parser error, so a step that unexpectedly gets back an HTML error page or an empty body tells you clearly what went wrong instead of throwing an opaque stack trace.
• Use JSON_SCHEMA (rather than chaining a dozen individual JSON_PATH assertions) when you actually care about the whole response shape – required fields present, correct types throughout – and reserve JSON_PATH assertions for the handful of specific values a test scenario is actually about.

• 📊 Data-Driven Testing (DDT) — Running the same chained request-and-assertion case once per row of a dataset instead of once per test.