How to use API Contract Validator
- Paste the OpenAPI or Swagger document.
- Enter the request: method, URL or path (query string included), optional headers and body.
- Enter the response status and optionally its headers and body.
- Click "Validate" and review the checks table — every FAIL row has matching violations below.
- Fix the request or the contract, then re-run until both directions conform.
API Contract Validator features
- OpenAPI 3.0/3.1 and Swagger 2.0 contracts in YAML or JSON with local $ref resolution
- Path template matching with parameters and automatic server base-path stripping
- Request checks: method, required path/query/header/cookie parameters, parameter types and enums, accepted Content-Type, body schema
- Response checks: documented status (2XX wildcards and default), declared headers, Content-Type and body schema
- Violation table with direction, location and message; warnings and info rows for likely mistakes
- Uses the same JSON Schema engine as the JSON Schema Validator (formats, nullable, composition)
API Contract Validator example
Create order with an invalid item and response
Input:
POST https://api.example.com/v1/orders
X-Request-Id: not-a-uuid
{ "customerId": "cus_8f2a", "items": [{ "sku": "SKU-1", "qty": 0 }] }
201 → { "id": "42", "status": "confirmed", "total": 59.9, "createdAt": "2026-09-01T10:00:00Z" }Output:
Conforms: No — 5 violations (2 request, 3 response)
request · header.X-Request-Id: Parameter "header.X-Request-Id": String is not a valid uuid.
request · body $.items[0].qty: Value must be ≥ 1. (minimum)
response · header.Location: Required response header "Location" is missing.
response · body $.id: Expected integer but got string. (type)
response · body $.status: Value must be one of: "pending", "paid", "shipped". (enum)Frequently asked questions about API Contract Validator
Which spec versions are supported?
OpenAPI 3.0 and 3.1 and Swagger 2.0, in YAML or JSON, with local $ref resolution for parameters, request bodies, responses and schemas.
How are paths matched?
The request URL (or path) is matched against path templates, preferring literal segments over parameters; server base paths (servers[].url or basePath) are stripped automatically.
What is validated on the request side?
Method existence, required path/query/header/cookie parameters with type and constraint checks, accepted Content-Type and the request body against its schema.
What is validated on the response side?
That the status is documented (including 2XX wildcards and default), declared response headers, the response Content-Type and the body against the schema for that status.
What do warnings and info rows mean?
Only "Violation" rows break conformance. Warnings flag likely mistakes (undocumented body, missing Content-Type); info rows note extras such as undeclared query parameters.
Technical notes
Query, path and header values arrive as strings, so the validator coerces them to the declared primitive type (integer, number, boolean, array via comma/pipe/space collection formats) before running the schema check. Objects in query parameters are parsed as JSON.
Content types are matched exactly first, then by wildcard (application/*, */*) and by structured-suffix family, so application/problem+json satisfies a contract that documents application/json. Schema validation runs with the whole document as $ref root, so #/components/schemas and #/definitions references resolve without copying.