Available on GitHub Marketplace

OpenAPI Validator & Diff
GitHub Action

Validate your OpenAPI spec and detect breaking changes on every pull request. Posts a detailed PR comment with errors, warnings, and an API diff — in seconds, no Docker required.

Supports OpenAPI 3.0, 3.1, 3.2 and Swagger 2.0. Free for public repos.

Free for public reposNo DockerRuns in secondsMIT licensed

Full OpenAPI validation

Validates against the OpenAPI 3.0, 3.1, 3.2 and Swagger 2.0 specifications. Returns structured errors with line numbers and JSON pointers.

Breaking change detection

Diffs the PR spec against your base branch and flags removed endpoints, new required fields, schema regressions and auth changes.

Rich PR comments

Posts a single, updating PR comment with a validation report, change summary and per-error details. No noisy reviewer floods.

Fast, no Docker

Pure JavaScript action — cold-starts in ~1 second on hosted runners. No image pulls, no JVM, no Python toolchain.

Block bad merges

Use as a required status check to prevent invalid specs — or breaking changes — from ever reaching main.

Free for open source

Public repos: unlimited validations, no account, no API key. Private repos use a free API key with a generous quota.

Quick start — add it in 30 seconds

Drop this file into .github/workflows/ and you're done.

.github/workflows/openapi-check.ymlPublic repo
name: OpenAPI Check
on:
  pull_request:
    paths:
      - 'openapi.yaml'
      - 'openapi.json'
      - 'docs/api/**'

permissions:
  contents: read
  pull-requests: write

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: apinotes/openapi-validate@v1
        with:
          spec-path: 'openapi.yaml'
Private repositoryAPI key required
      - uses: apinotes/openapi-validate@v1
        with:
          api-key: ${{ secrets.APINOTES_API_KEY }}
          spec-path: 'openapi.yaml'

Create a free key at apinotes.io → Dashboard → Settings → API Keys, then store it as APINOTES_API_KEY in your repo secrets.

What reviewers see on the PR

A single, structured comment — no email noise, no separate dashboards.

AN
apinotes-bot commented on this pull request

✅ OpenAPI Validation Report

Fileopenapi.yaml
StatusValid
OpenAPI Version3.1
Errors0
Warnings2

🔀 API Diff (vs base branch)

➕ Added endpoints2
✏️ Changed endpoints1
➖ Removed endpoints0
⚠️ Breaking changes1

Breaking changes the diff engine catches

Built on the same engine that powers our online OpenAPI diff tool. Every change is classified by severity so reviewers can focus on what matters.

Breaking
  • 🔴 Removed endpoints or methods
  • 🔴 Required parameters added
  • 🔴 Response schema fields removed
  • 🔴 Authentication requirements changed
  • 🔴 Type narrowing in request body
Warning
  • 🟠 OperationId changes
  • 🟠 Endpoints marked deprecated
  • 🟠 Optional parameter removed
  • 🟠 Enum values removed
  • 🟠 Status code dropped
Info
  • ℹ️ New endpoints added
  • ℹ️ New optional fields
  • ℹ️ Tag & description changes
  • ℹ️ New enum values
  • ℹ️ Examples updated

Configuration

InputDefaultRequiredDescription
spec-pathopenapi.yamlYesPath to your OpenAPI specification file (YAML or JSON).
api-keyPrivate repos onlyYour ApiNotes API key, stored as a GitHub secret.
diff-enabledtrueNoDiff against the base branch and report breaking changes.
fail-on-errorstrueNoFail the workflow if the spec contains validation errors.
fail-on-breakingfalseNoFail the workflow when breaking changes are detected.
comment-on-prtrueNoPost the validation report as a PR comment.

Block PRs with invalid specs

Make the action a required status check to enforce a clean OpenAPI spec on main. Optionally fail the build when breaking changes are detected.

  1. Repository → SettingsBranches
  2. Add a branch protection rule for main
  3. Enable Require status checks to pass before merging
  4. Search for and select the validate job
  5. Set fail-on-breaking: true in your workflow to also block breaking changes

Why this action vs other OpenAPI tools?

Most teams stitch together openapi-spec-validator, oasdiff or openapi-diff, plus a custom GitHub script for PR comments. This action does it in one step.

Capabilityopenapi-spec-validatoroasdiff / openapi-diffApiNotes Action
OpenAPI 3.0 / 3.1 / 3.2 validation✅ partial
Swagger 2.0 support
Breaking change detection
PR comments out of the box
No Docker / no JVM❌ (oasdiff Go binary)
One step in workflow❌ (multi-step)❌ (multi-step)
Free for public repos

Pricing

Free for public repos forever. Generous free tier for private repos.

Open Source

Free

Public repositories

  • ✅ Unlimited validations
  • ✅ No account required
  • ✅ No API key
  • ✅ All features included

Starter

Free

Private repositories

  • ✅ 8 validations / month
  • ✅ Free API key
  • ✅ All features included
Most popular

Developer

$6.99/mo

Private repositories

  • ✅ 1,000 validations / month
  • ✅ Priority support
  • ✅ All features included

Frequently asked questions

Is this the same as openapi-spec-validator or oasdiff?
No — it combines both. The action validates your spec (like openapi-spec-validator or Swagger Editor) and diffs it against your base branch (like oasdiff / openapi-diff), then posts a single, structured PR comment. You don't need to glue together multiple tools.
Which OpenAPI versions are supported?
OpenAPI 3.2, 3.1, 3.0 and Swagger 2.0. The action automatically detects the version from the document.
Do I need an account or API key for public repos?
No. Public GitHub repositories use the action with no API key — unlimited validations, no signup. An account is only required for private repositories.
How does breaking change detection work?
When a PR opens, the action fetches the spec from the base branch, diffs it against the PR version using the same engine that powers our online OpenAPI diff tool, and classifies each change as breaking, warning or info. Make sure to use fetch-depth: 0 in actions/checkout so the base ref is available.
Can I block PRs with invalid specs or breaking changes?
Yes. The action exits non-zero when validation fails (default) and optionally when breaking changes are detected (fail-on-breaking: true). Add the job as a required status check in your branch protection rules and bad PRs cannot be merged.
Where is my OpenAPI spec sent?
Validation and diffing happen via the ApiNotes API. The spec is processed in-memory to produce the report and is not persisted. For public repos, no authentication is required. For private repos, requests are scoped to your API key.
How does this compare to Spectral or IBM's openapi-validator?
Spectral and IBM's validator focus on linting/style rules. This action focuses on spec validity and breaking change detection with native PR comments. They're complementary — many teams run both.
Is the action open source?
Yes — the action wrapper is MIT-licensed. View source on GitHub.

Ship safer API changes today

Catch invalid OpenAPI specs and breaking changes before they reach production. Install the action in 30 seconds.