Conditions and Assertions
Conditions and assertions are rules attached to a monitor that determine whether each response is classified as a pass, warning, or failure. Without conditions, APIContext uses sensible defaults (2xx = pass, 4xx = warning, 5xx = error). With conditions, you define exactly what "correct" means for each endpoint.
Conditions vs. assertions
The terms are used interchangeably in parts of the UI, but they serve slightly different roles:
- Conditions control flow — they decide what happens after a call completes, such as whether a workflow should stop on failure
- Assertions verify data — they check that specific parts of the response match expected values
In practice, both are configured in the same place and both contribute to the pass/fail/warning verdict.
What you can check
| Check type | Example |
|---|---|
| HTTP status code | Expect 200; treat 500 as a pass for negative testing |
| Response header | Content-Type must equal application/json |
| Response body (string) | Body must contain the word "success" |
| JSON path | user.id must equal 5 |
Raw response (_raw) | Full response body must match an exact string or contain a substring |
| Response size (bytes) | Response must be less than 100 bytes, or exactly 0 for empty-body checks |
| Latency | Total latency over 1000 ms triggers a "passed but slow" result |
How conditions affect other features
- Alerts fire based on the verdict that conditions produce — a warning condition triggers warning alerts, an error condition triggers error alerts
- CASC Quality Score uses the pass/fail ratio driven by conditions as its primary input
- Workflows can stop at the first failing step, which is determined by that step's conditions
See also
- Setting assertions and conditions — how to configure conditions in the UI
- Alerts and webhooks — what happens when a condition triggers a non-pass verdict
- CASC Score — how pass/fail rates flow into the quality score