API Contract Validator
Validate observed API behavior against an identified contract version.
Inputs and evidence
Require the contract, its version or revision, and a captured request/response or runner
output. Record the method, path, status, media type, and evidence source. Mark missing
material Not provided; never synthesize traffic.
Workflow
- Resolve the observed exchange to the exact contract operation and response.
- Check documented status, headers, required fields, types, nullability, enums, formats,
and additional-property rules.
- Classify every check as
Conforms, Mismatch, Ambiguous, or Not verifiable.
- Cite the contract pointer and minimal redacted evidence for every finding.
- Separate implementation drift from possible contract staleness; do not choose a source
of truth without owner confirmation.
- HUMAN REVIEW GATE (mandatory). Ask the API owner to confirm the contract version
and findings before recommending a specification or implementation change.
Output shape
| Check |
Contract pointer |
Observed evidence |
Result |
Follow-up |
Include the evidence source, contract revision, unresolved ambiguities, and review decision.
Guardrails
- Treat examples as examples, not schema constraints.
- Never mark an unobserved check as passing or fabricate a response, field, or result.
- Redact tokens, cookies, keys, personal data, and confidential payload values.
- Do not call a live endpoint unless the user confirms authorization, target environment,
and request scope; default to offline evidence review.
1---2name: api-contract-validator-23description: Compare observed HTTP API requests and responses with an OpenAPI or equivalent endpoint contract. Use when asked to validate a response against an HTTP specification, find API contract drift, check status codes or headers, or review captured request and response evidence. Produce a conformance report without designing general API coverage; use a message-specific validator for AsyncAPI and standalone JSON Schema artifacts.4license: MIT5---67# API Contract Validator89Validate observed API behavior against an identified contract version.1011## Inputs and evidence1213Require the contract, its version or revision, and a captured request/response or runner14output. Record the method, path, status, media type, and evidence source. Mark missing15material `Not provided`; never synthesize traffic.1617## Workflow18191. Resolve the observed exchange to the exact contract operation and response.202. Check documented status, headers, required fields, types, nullability, enums, formats,21 and additional-property rules.223. Classify every check as `Conforms`, `Mismatch`, `Ambiguous`, or `Not verifiable`.234. Cite the contract pointer and minimal redacted evidence for every finding.245. Separate implementation drift from possible contract staleness; do not choose a source25 of truth without owner confirmation.266. **HUMAN REVIEW GATE (mandatory).** Ask the API owner to confirm the contract version27 and findings before recommending a specification or implementation change.2829## Output shape3031| Check | Contract pointer | Observed evidence | Result | Follow-up |32|---|---|---|---|---|3334Include the evidence source, contract revision, unresolved ambiguities, and review decision.3536## Guardrails3738- Treat examples as examples, not schema constraints.39- Never mark an unobserved check as passing or fabricate a response, field, or result.40- Redact tokens, cookies, keys, personal data, and confidential payload values.41- Do not call a live endpoint unless the user confirms authorization, target environment,42 and request scope; default to offline evidence review.
PramodDutta