Correct the reported OpenAPI structure

Resolve schema and object-shape errors before requesting a repair.

Match the finding

These titles and messages come from this local checker. They are not AWS service error quotes.

Cause and scope

Parsing a document does not establish that it is valid OpenAPI. The checker inspects known objects and uses a pinned OpenAPI 3.0 schema; either layer can block automatic repair.

What to do

Use the finding path and message to locate the exact object, check its expected type and required fields, then recheck the complete document.

  1. Inspect the reported location. The empty JSON Pointer is the document root; ~1 and ~0 in a token represent / and ~.
  2. Compare the object with the matching OpenAPI definition. Common requirements include string info.title and info.version, an object paths, and responses with descriptions.
  3. Fix the actual type or required field and rerun checks until no structural errors remain.

Minimal complete OpenAPI 3.0 document

openapi: 3.0.3
info:
  title: Pet API
  version: '1.0.0'
paths:
  /pets:
    get:
      responses:
        '200':
          description: OK

This illustrates required structure, not a replacement for your API. Quote YAML response codes so their mapping keys are strings. Retain your existing routes, security, schemas, and extensions.

Avoid a misleading fix

Do not add placeholder objects or delete unrecognized fields without understanding their purpose. Never clear security just to satisfy a shape error.

Check your complete file locally

Choose one OpenAPI 3.0 JSON or YAML file, diagnose the findings, and review any eligible security-copy preview before downloading. No file upload or account is needed.

Open the free OpenAPI checker →

Related findings

Sources and scope

Scope: this local checker, API Gateway REST APIs, and OpenAPI 3.0. Guidance reviewed 4 October 2026. A passing check does not guarantee import or runtime behavior.