Does it support Swagger 2.0?

Yes. The validator detects top-level Swagger 2.0 documents and scores the same documentation quality categories, although the recommendations are optimized for modern OpenAPI 3.x specs.

Is my OpenAPI file uploaded to Ferndesk?

The spec is sent to a Ferndesk server endpoint for validation and URL fetching, but the tool does not store it. Server-side fetching lets us avoid browser CORS failures and apply public-URL safety checks.

What is agent-ready API documentation?

Agent-ready API docs are specific enough for AI coding tools and support agents to call the right endpoint safely: stable operation IDs, clear summaries, realistic examples, auth rules, error states, pagination, and rate-limit behavior.

How is this different from Swagger Editor or a schema validator?

Traditional validators focus on whether the spec can be parsed. This tool also scores whether developers and AI agents can understand and use the API without guessing.

OpenAPI validator

Free OpenAPI & Swagger validator

Paste, upload, or link an OpenAPI or Swagger spec and get an instant readiness score across syntax, completeness, examples, auth, responses, changelogs, and AI agent-readiness.

Free to use, no signup
Your spec is never stored
JSON or YAML, OpenAPI 3.x and Swagger 2.0

{} OpenAPI specification

openapi: 3.1.0
info:
  title: Acme Billing API
  version: 2026-05-01
  description: Manage customers, invoices, subscriptions, and usage events.
servers:
  - url: https://api.acme.test/v1
security:
  - bearerAuth: []
tags:
  - name: Customers
    description: Customer records used for billing and lifecycle automation.
paths:
  /customers:
    get:
      tags:
        - Customers
      operationId: listCustomers
      summary: List customers
      description: Returns paginated customers ordered by creation date.
      parameters:
        - name: limit
          in: query
          description: Maximum number of customers to return.
          schema:
            type: integer
            default: 25
      responses:
        '200':
          description: A page of customers.
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: array
                    items:
                      $ref: '#/components/schemas/Customer'
              examples:
                success:
                  value:
                    data:
                      - id: cus_123
                        email: founder@example.com
        '401':
          description: Missing or invalid bearer token.
        '429':
          description: Rate limit exceeded.
  /customers/{customerId}:
    get:
      tags:
        - Customers
      operationId: getCustomer
      summary: Retrieve a customer
      description: Fetches one customer by stable customer ID.
      parameters:
        - name: customerId
          in: path
          required: true
          description: Stable customer identifier.
          schema:
            type: string
      responses:
        '200':
          description: Customer found.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Customer'
        '404':
          description: Customer not found.
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: Send a short-lived access token in the Authorization header.
  schemas:
    Customer:
      type: object
      description: A billing customer.
      required:
        - id
        - email
      properties:
        id:
          type: string
          description: Stable customer identifier.
          example: cus_123
        email:
          type: string
          format: email
          description: Customer email address.
          example: founder@example.com
externalDocs:
  description: API changelog
  url: https://acme.test/changelog
x-changelog:
  - date: 2026-05-01
    description: Added customer retrieval endpoint.

Documentation quality

Validating your spec…

What it checks

More than schema validation

Most validators answer one question: will tooling accept this file? This checker also asks whether your API reference is complete enough for a developer, support agent, or AI coding tool to take the next step without guessing.

Syntax

Required top-level fields, the OpenAPI or Swagger version, paths, operations, and whether the document parses at all.

Completeness

API overview, server URLs, endpoint summaries, descriptions, parameters, tags, and reusable schemas.

Examples

Request examples, response examples, and schema examples, the real payloads a developer can copy and run.

Authentication

Security schemes, global and operation-level requirements, OAuth and API key clarity, and auth failure states.

Response docs

2xx success responses, 4xx and 5xx errors, descriptions, content types, schemas, and empty-response rules.

Changelogs

Versioning, release notes, deprecations, migration context, and links to the API change history.

Agent-readiness

Stable operation IDs, unambiguous descriptions, examples, schema clarity, rate limits, and safe error handling.

Agent-ready docs

Valid OpenAPI is the floor. Agent-readiness is the bar.

AI coding assistants, support agents, and workflow automations read API docs differently from humans. They need stable names, explicit input rules, response shapes, auth behavior, error states, and examples that remove ambiguity.

That is why this validator scores operation IDs, descriptions, examples, schemas, 401 and 403 responses, 429 behavior, changelog links, and deprecation signals. Those details help agents call your API safely instead of guessing from a syntactically valid file.

OpenAPI validator FAQ

Practical answers for API teams, technical writers, and developers maintaining API docs.

It checks syntax, required OpenAPI structure, documentation completeness, examples, authentication, response documentation, changelog signals, and AI agent readiness.