DevOps & Cloud · API breaking-change guard

ContractCheck

Ship APIs that don't break clients.

Catch renamed fields, new required parameters and removed endpoints in the pull request, long before a partner finds them in production.

Teams with a public or partner APIFintech and SaaS platformsPlatform teams with many services

Book a ContractCheck demo See pricing

api-guard · example

$ api-guard orders-v1.json orders-v2.json
api-guard: 11 breaking, 6 warning(s), 3 safe change(s)
✖ DELETE /orders/{id}: Operation removed
✖ POST /orders: New required field currency in the request
✖ POST /orders: Type of items[].qty changed from integer to string
! GET /orders/{id}: New values in status: refunded

Real run on the sample specs included with the product.

SpecsOpenAPI

FindsBreaking changes

Runs onYour laptop, server or CI

Shows inPull request

The problem

A renamed field or a new required parameter looks harmless in review. Then mobile apps and partner integrations start failing, and nobody knows which change did it.

What it does

Compares the OpenAPI spec in a pull request with the base branch (JSON or YAML)

Flags removed endpoints, new required inputs, type changes, removed response fields, removed enum values and newly required auth

Warns on changes that break strict clients: new response enum values, fields no longer always present

Plain-English reason for every finding, so product managers understand it too

PR comment, job summary and a failing check; an allow-breaking label for planned breaks

Text, markdown and JSON reports for any CI

How it works

Point the action at your spec
Every pull request is compared with the base branch
Fix the break, version it, or approve it on purpose

Works with

OpenAPIGitHub Actions

Runs in your CI

GitHub Actions workflow step

- uses: actions/checkout@v5
- uses: Deepanshu18Saini/api-guard@main
  with:
    spec: openapi.yaml
    fail-on: breaking

Licensed customers get the action or command-line tool installed in their own organisation; it runs on your runners, so your code and plans never leave them. The command-line tools run in GitLab CI the same way.

Your data

Compares spec files in your pipeline.
Nothing is called or deployed.
Works offline.

Who it's for

Teams with a public or partner APIFintech and SaaS platformsPlatform teams with many services

Questions

What counts as breaking?

Anything an existing client would feel: removed or renamed endpoints and fields, new required inputs, narrowed types.

Can we allow intentional breaks?

Yes, with an explicit, reviewed exception.

Often used with ContractCheck

DevOps & Cloud

BlastRadar

Change impact analysis

Know what a change will touch. Before a release, see every service a change can affect and the line of code that links it. After the release, confirm those services are still healthy.

$300–600 (₹10,000–20,000 in India)View product → DevOps & Cloud

SLOStudio

SLOs and error budgets

Reliability you can measure. Define each SLO in a few lines and get correct burn-rate alerts, an error budget everyone understands, and a release gate, on the monitoring you already run.

$1,500–3,000 (₹40,000–80,000 in India)View product → DevOps & Cloud

TestScope

Test impact selection

Run the tests that matter. Every pull request runs the tests its change can affect, each with a stated reason, and the full suite whenever a change is too broad to trust.

$1,000–2,500 (₹25,000–60,000 in India)View product →

← PreviousPlanGuard Next →CloudExit

See ContractCheck on your own data

A 30-minute call. We run the product on your export, repository or document and walk you through the results.

Book a demo