> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quixa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Assertions & Validation Engine

> Verify HTTP status codes, latency SLAs, headers, and JSON body properties with automated assertion retry policies.

Data generation without continuous validation creates silent false positives. In Quixa, every visual node includes an **Assertion & Validation Engine** that executes comprehensive checks immediately upon receiving a response.

***

## 1. Supported Assertion Targets

| Target | Description | Example Rule |
| :- | :- | :- |
| **Status Code** | Verifies the returned HTTP response status. | `Status Code EQUALS 200` |
| **Response Time (ms)** | Enforces latency SLAs for performance regression testing. | `Response Time LESS_THAN 500` |
| **Header** | Checks for header presence, exact match, or regex. | `Header "content-type" CONTAINS "application/json"` |
| **JSON Body Field** | Evaluates specific fields extracted via dot notation or JSONPath. | `body.data.status EQUALS "ACTIVE"` |
| **JSON Schema** | Validates the entire payload against an OpenAPI JSON Schema. | `Matches OpenAPI Response Schema` |

***

## 2. Comparison Operators

* **`equals` / `notEquals`**: Strict equality checks against strings, numbers, or booleans.
* **`contains` / `notContains`**: Substring verification or array membership checks.
* **`greaterThan` / `lessThan`**: Numeric boundary and latency thresholds.
* **`matchesRegex`**: Regular expression validation (e.g. email format, UUID patterns, ISO timestamps).
* **`hasProperty` / `doesNotHaveProperty`**: Validates whether a key exists in the response object regardless of value.

***

## 3. Dynamic Token Assertions

Assertions support full token interpolation. You can compare the response of a node against values generated earlier in the flow:

```handlebars theme={null}
body.customerId EQUALS {{ResponseBinding.CreateCustomer.body.customerId}}
body.email EQUALS {{QMock.internet.email}}
headers['x-correlation-id'] EQUALS {{flow.correlationId}}
```

This guarantees true end-to-end data integrity across distributed microservices.

***

## 4. Assertion Retry Policy

In distributed environments, downstream state may take several hundred milliseconds to become consistent. Rather than failing the flow immediately on a momentary mismatch, Quixa supports **Assertion Retries**:

* **Max Retries**: The maximum number of retry attempts (e.g., `3`).
* **Retry Interval (ms)**: Wait duration between attempts (e.g., `1000 ms`).
* **Execution**: If an assertion fails, Quixa automatically re-invokes the HTTP request after the configured interval until the assertion passes or the retry limit is exhausted.

***

## 5. Visual Reporting of Assertion Outcomes

During workflow execution, assertion results are displayed with color-coded badges in the **Execution Results Panel**:

* 🟢 **Green Badge**: All assertion rules passed successfully.
* 🔴 **Red Badge**: Highlights the exact assertion that failed, showing the **Expected** versus **Actual** values.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.