OpenAPI response validator

Input
Output

OpenAPI Response Validator

Paste a response and the OpenAPI document that describes it, and see every way the body breaks the contract: a required field that's missing, a string where a number belongs, a value outside its enum, pattern or range. Pick the operation by GET /path or by the address the response came from.

Example: an order that breaks its contract

The response came back from GET /orders/ORD-20419. The spec says status is one of four values, total is a number, placedAt is a date-time and every item has at least one. Four problems, and two fields the spec doesn't mention:

The response

{
  "id": "ORD-20419",
  "status": "refunded",
  "total": "4248.50",
  "currency": "INR",
  "note": null,
  "placedAt": "2026-10-08 14:32",
  "items": [
    {
      "sku": "KB-01",
      "qty": 0,
      "price": 2499
    },
    {
      "sku": "MS-07",
      "qty": 1,
      "price": 1749.5,
      "giftWrap": true
    }
  ],
  "trackingUrl": "https://track.example.com/ORD-20419"
}

The OpenAPI document

openapi: 3.0.3
info:
  title: Orders API
  version: "1.4"
paths:
  /orders/{orderId}:
    get:
      operationId: getOrder
      parameters:
        - {name: orderId, in: path, required: true, schema: {type: string}}
      responses:
        "200":
          description: The order
          content:
            application/json:
              schema: {$ref: "#/components/schemas/Order"}
        "404":
          description: No such order
          content:
            application/json:
              schema: {$ref: "#/components/schemas/Error"}
components:
  schemas:
    Order:
      type: object
      required: [id, status, total, currency, items]
      properties:
        id: {type: string, pattern: "^ORD-\\d+$"}
        status: {type: string, enum: [pending, paid, shipped, cancelled]}
        total: {type: number, minimum: 0}
        currency: {type: string, minLength: 3, maxLength: 3}
        note: {type: string, nullable: true}
        placedAt: {type: string, format: date-time}
        items:
          type: array
          minItems: 1
          items: {$ref: "#/components/schemas/Item"}
    Item:
      type: object
      required: [sku, qty, price]
      properties:
        sku: {type: string}
        qty: {type: integer, minimum: 1}
        price: {type: number}
    Error:
      type: object
      required: [code, message]
      properties:
        code: {type: string}
        message: {type: string}

Output

GET /orders/{orderId} → 200: 4 problems
✕ $.status: Must be one of "pending", "paid", "shipped", "cancelled"
✕ $.total: Expected number, got string
✕ $.placedAt: Must be a valid date-time
✕ $.items[0].qty: Must be at least 1 (got 0)
Not in the spec: $.items[1].giftWrap, $.trackingUrl

How do I use the OpenAPI response validator?

  1. Paste the response body (JSON) in the first box.
  2. Paste the OpenAPI 3.x document, JSON or YAML, in the second box.
  3. Type the operation, such as GET /orders/{id} or the full address, or leave it blank for the best fit; read every problem with its path.

What does the OpenAPI response validator do?

  • $ref, allOf, oneOf and nullable from the spec, resolved
  • The operation found from a method and path, or a whole address
  • Fields the spec doesn't list, a sign it's behind the API

When to use the OpenAPI response validator

An OpenAPI document is a promise: this endpoint returns these fields, of these types, with these values. Front ends, mobile apps and generated clients are built on that promise, so a response that quietly breaks it causes bugs far from the API. Checking one real response against the spec catches that early, whether you're testing a new release, reviewing a backend change or arguing about whose bug it is.

Bracely finds the operation's response in the document, from GET /orders/{orderId} or an address like https://api.example.com/orders/ORD-20419 matched against the path templates, and picks the success response unless you name a status. Without an operation, it uses the response the body fits exactly, then the closest success response. References under #/components are resolved, OpenAPI 3.0's nullable: true allows null, and 3.1 schemas are read as the JSON Schema they are. Fields the body has and the spec doesn't list are reported separately: they're allowed unless additionalProperties is false, but usually mean the document is behind the API.

Frequently asked questions

Does it check the request too?
No, only the response body against the operation's response schema. Headers and status codes aren't checked; the status you name only picks which schema to use.
Can I check every endpoint at once?
Not here: this checks one response. To check many, use API tests with a list of requests and a schema line per request, or run the same responses through this tool one by one.
Is my data uploaded?
No. Bracely runs entirely in your browser, so nothing you paste or open leaves your device.

More JSON tools

Bracely has 104 JSON tools in one page. Related ones:

Runs entirely in your browser. Nothing you paste is uploaded. Made by Saurabh Pagrut · About · Privacy policy
Last updated · Version 6.1 · Changelog
Saurabh Pagrut on GitHub · LinkedIn · X · YouTube · Instagram