Response Validator Generation from OpenAPI Prompt Template

This prompt is designed for integration test engineers and SDETs who need to automate the assertion side of API testing. Its primary job is to consume an OpenAPI 3.x specification and produce executable validation functions that check a live API response for status code correctness, response body schema conformance, required header presence, and data type accuracy. You should use this prompt when you have a machine-readable spec, a specific operationId or path-method pair, and a target HTTP response code (e.g., 200 or 404). The ideal user is someone building a test harness who wants to drop in a ready-made validator rather than manually writing assertions for every endpoint.

The prompt requires three concrete inputs to be useful: a complete or partial OpenAPI document, a target operation identifier, and the expected response status code. It does not generate test data, request payloads, or full test cases—it focuses exclusively on the response validation logic. This means it is not a replacement for a full contract-testing framework like Pact or a schema fuzzer. It also does not handle multi-step workflows, authentication flows, or stateful API sequences. If you need to generate request bodies, test sequences, or consumer-driven contracts, use the sibling prompts for CRUD Lifecycle Test Sequences or Consumer-Driven Contract Tests instead.

Before using this prompt, ensure your OpenAPI spec is structurally valid and that the target operation's response schemas are defined with enough detail to generate meaningful assertions. The prompt works best with OpenAPI 3.x documents that include explicit JSON Schema definitions for response bodies and documented headers. Avoid using this prompt for operations with undocumented or highly dynamic responses, as the generated validators will be brittle. If you are working in a regulated or high-risk domain where false negatives could mask production issues, pair the generated validators with human review of the assertion logic and run them against a golden dataset of known valid and invalid responses to calibrate sensitivity.

This prompt template instructs the model to act as an API test engineer and produce a structured set of response validators from a provided OpenAPI specification. It is designed to be self-contained: you supply the spec, the target endpoint, and your risk tolerance, and the model returns a JSON array of validation rules covering status codes, response body schema, headers, and error conditions. The output is intended for direct consumption by an automated test harness, not just for human review.

textCopy
You are an API test engineer building an automated response validation suite. Your task is to analyze the provided OpenAPI specification and generate a comprehensive set of response validators for the specified endpoint.

## INPUTS
- OpenAPI Specification: [OPENAPI_SPEC]
- Target Endpoint (method + path): [TARGET_ENDPOINT]
- Risk Level: [RISK_LEVEL] // One of: 'low', 'medium', 'high'

## CONSTRAINTS
- Generate validators ONLY for the status codes defined in the specification for this endpoint.
- For each status code, validate the response body against the defined schema, required headers, and content-type.
- For error responses (4xx, 5xx), include validators for the standard error schema if one is defined.
- Flag any optional fields that are critical for the client as 'should-validate' with a justification.
- If the spec defines examples, include them as expected values for positive test cases.

## OUTPUT_SCHEMA
Return a JSON object with a single key "validators" containing an array of validator objects. Each validator object must have the following structure:
{
  "validatorId": "string",
  "description": "string",
  "expectedHttpStatus": "integer",
  "schemaAssertions": [
    {
      "jsonPath": "string",
      "type": "string", // 'type', 'required', 'enum', 'pattern', 'minimum', 'maximum'
      "expectedValue": "any",
      "severity": "string" // 'must-validate' or 'should-validate'
    }
  ],
  "headerAssertions": [
    {
      "headerName": "string",
      "expectedValue": "string",
      "severity": "string"
    }
  ],
  "errorSchemaAssertions": [] // Same structure as schemaAssertions, used for error responses
}

## RISK_LEVEL ADAPTATION
- low: Focus on happy-path status codes and required fields only.
- medium: Include all documented status codes, required fields, and critical optional fields.
- high: Include all documented status codes, all fields, header validation, and error schema conformance. Add validators for undocumented but common error codes (e.g., 429, 503) with a 'should-validate' severity.

To adapt this template, replace the placeholders with your concrete inputs. For [OPENAPI_SPEC], you can paste the raw YAML/JSON or provide a reference to a file path if your tooling supports it. The [TARGET_ENDPOINT] should be a string like GET /users/{id}. The [RISK_LEVEL] parameter directly controls the breadth and strictness of the generated assertions, allowing you to tune the prompt for a quick smoke test versus a full compliance gate. After generating the validators, always run them through a schema validation step to ensure the model's JSON output conforms to the OUTPUT_SCHEMA before feeding it to your test runner.

This prompt is designed to be called programmatically from a test generation pipeline, not as a one-off chat interaction. The typical integration point is a CI/CD step that reads an OpenAPI specification file, sends it to the model with this prompt template, and writes the generated validators into a test suite directory. The harness must handle the full lifecycle: spec ingestion, prompt assembly, model invocation, output parsing, structural validation, and integration into the target test framework. Treat the generated validators as draft assertions that require automated verification before they become part of the regression suite.

The implementation harness should enforce a strict validate-before-commit pattern. After the model returns a response, parse the JSON output and run it through a structural validator that checks: (1) every referenced endpoint and operation exists in the source OpenAPI spec, (2) status code assertions match the documented responses for each operation, (3) response body validators reference real schema components, (4) header assertions target documented headers, and (5) the output conforms to the expected [OUTPUT_SCHEMA] format. If structural validation fails, retry the prompt once with the validation errors appended as feedback in a [CORRECTION_CONTEXT] placeholder. After two failures, flag the spec section for manual review rather than looping indefinitely. Log every validation pass and failure with the spec version, model version, and timestamp for auditability.

For production use, implement a false-positive and false-negative detection harness around the generated validators. Run each validator against a set of known-valid and known-invalid response fixtures derived from the spec examples or recorded traffic. A validator that rejects a known-valid response is a false positive; one that accepts a known-invalid response is a false negative. Track these rates per endpoint and set a quality gate—for example, require zero false positives and less than 5% false negatives before validators are promoted to the test suite. Route validators that fail this gate to a human review queue with the specific failure cases attached. This harness turns the prompt from a generator into a measurable, gate-controlled component of the test pipeline.