> ## 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.

# OpenAPI Shadow Flows (Negative Testing)

> Automatically generate comprehensive negative test flows from OpenAPI specifications to validate error resilience.

Most engineering teams focus testing efforts exclusively on "Happy Paths" (HTTP 200/201 responses). However, in production microservices, resilience against malformed inputs, unauthorized access, and domain conflicts is critical.

Quixa solves this through **Automated OpenAPI Shadow Flows**.

```mermaid theme={null}
flowchart TD
    Spec["OpenAPI 3.0 Specification"] --> Engine["Quixa Shadow Flow Generator"]
    Engine --> Happy["Primary Flow: HTTP 200 OK (Happy Path)"]
    Engine --> S400["Shadow Flow: HTTP 400 Bad Request (Missing Required Fields)"]
    Engine --> S401["Shadow Flow: HTTP 401 Unauthorized (Invalid Token)"]
    Engine --> S409["Shadow Flow: HTTP 409 Conflict (Duplicate Unique Entity)"]
    Engine --> S422["Shadow Flow: HTTP 422 Unprocessable Entity (Range Violation)"]

    style Engine fill:#7c3aed,stroke:#a78bfa,stroke-width:2px,color:#fff
    style Happy fill:#059669,stroke:#34d399,stroke-width:2px,color:#fff
    style S400 fill:#b91c1c,stroke:#f87171,stroke-width:2px,color:#fff
    style S401 fill:#b91c1c,stroke:#f87171,stroke-width:2px,color:#fff
    style S409 fill:#b91c1c,stroke:#f87171,stroke-width:2px,color:#fff
    style S422 fill:#b91c1c,stroke:#f87171,stroke-width:2px,color:#fff
```

***

## 1. How Shadow Flows Work

When an API collection is imported or updated via **Quixa SpecTrum™**, the platform inspects the defined OpenAPI response models. For every endpoint with documented non-200 responses, Quixa can synthesize corresponding **Shadow Flows**:

### Automated Negative Permutations

1. **HTTP 400 (Bad Request)**: Automatically generates payloads with omitted required properties, invalid date strings, or string values injected into integer fields.
2. **HTTP 401 (Unauthorized)**: Dispatches requests with expired, malformed, or missing `Authorization` Bearer tokens.
3. **HTTP 403 (Forbidden)**: Dispatches requests using valid credentials that lack the required RBAC/ReBAC roles or scopes.
4. **HTTP 409 (Conflict)**: Dispatches idempotent requests twice in succession to verify duplicate key prevention.
5. **HTTP 422 (Validation Failure)**: Tests boundary conditions (e.g., negative amounts, string length exceedances).

***

## 2. Standardized Error Envelope Verification

Shadow Flows verify that backend services return standardized RFC 7807 problem details or enterprise error envelopes:

```json theme={null}
{
  "type": "https://api.example.com/errors/invalid-parameters",
  "title": "Invalid Request Parameters",
  "status": 400,
  "detail": "Field 'email' must be a valid email format.",
  "instance": "/api/v1/customers",
  "correlationId": "corr_83912048"
}
```

### Assertions in Shadow Flows

Each generated shadow flow automatically attaches assertions to verify:

* Exact error status code match (`status == 400`).
* Standardized error structure containing `title`, `detail`, and `correlationId`.
* **Zero Leak Guard**: Asserts that responses never expose internal stack traces, database table names, or raw SQL queries to consumers.

***

## 3. Running Shadow Flows in Regression Suites

Shadow flows are saved directly in your flow catalog and can be added to regular **Flow Suites**. Running shadow flows as part of nightly CI/CD regression pipelines ensures that API security and error handling policies remain intact across production deployments.


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