Which vendor API changes actually touch the endpoints you call

You call thirty endpoints. The vendor changed fourteen hundred things. A CI check reads the list of endpoints you actually call, compares the vendor's own OpenAPI specification against the revision you pinned, and reports the ones that touch yours.

It runs in your CI. It needs no credentials, no repository access, and nothing is uploaded anywhere. The check itself is free and its source is public.

Install the check Read a real report first

Why this exists, in numbers rather than adjectives

Between 12 March 2026 and 16 September 2026, the GitHub REST specification went from 1093 operations to 1239. In that window it removed 8 and newly deprecated 7. 38 operations in the current specification are marked deprecated, which is to say they have a clock on them.

Nobody emailed you about the ones you call. That is the whole product.

Measured from github/rest-api-description at f7af1e5 and 29bcb55. Every operation, named.

Two files and you are done

A manifest listing what you call and the specification revision you last reconciled against:

{
  "version": 1,
  "integrations": [
    {
      "vendor": "github",
      "baseline": "2026-03-19",
      "endpoints": [
        "GET /repos/{owner}/{repo}/issues",
        "POST /repos/{owner}/{repo}/check-runs"
      ]
    }
  ]
}

And a workflow:

# .github/workflows/apibreak.yml
name: apibreak
on:
  schedule: [{ cron: "0 7 * * 1" }]
  workflow_dispatch:

jobs:
  apibreak:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Skyblueballykid/apibreak@v1
        with:
          manifest: apibreak.json
          fail-on: breaking

The run writes a table into your job summary and exits non-zero when something breaking lands. Exit code 2 is a breaking finding, 1 is a problem with the manifest, 0 is nothing to do.

What it reports, and only this

Removed operations — in your pinned revision, gone from the current one.
Newly deprecated operations — the notice period, while you still have one.
Request fields that became required — at any depth, including inside array elements — and parameters that became required, including the ones a vendor declares once on the path and never repeats. A new required field inside a brand-new optional object is not reported: nobody was sending that object.
Fields that changed type, and fields that were unrestricted and now accept only a fixed set.
Request or response fields that disappeared. A response field vanishing is the change that breaks a parser without anyone announcing it.
Enum members that no longer exist, with the values that replaced them.

Purely additive changes are counted and not listed. A check that reports every new optional field teaches you to ignore it.

What it refuses to do

It does not read your source code, and it does not want access to your repository.
It does not take credentials, API keys or traffic.
It does not fix anything automatically.
It does not claim complete coverage. A schema it cannot read honestly — a oneOf union, an unresolvable reference, a chain deeper than it follows — is reported as not compared, on every run, never as clean. Those rows do not fail your build: they are a standing limit, not a failure. An endpoint it could not read at all is unknown and does fail, because a check that could not look is not a check that passed.
It does not compare fields a vendor never enumerated. A free-form object has nothing to remove; if a vendor stops enumerating fields it used to list, that is reported as not compared rather than as a pile of removals.
It does not tell you your integration is broken. Where a vendor pins API versions per account, as Stripe does, a specification change is an upgrade impact, and the report says so in those words.

Vendors it knows, and why those

Each vendor here was measured before it was supported. A vendor whose specification does not move is not a monitoring subject, and adding names to look impressive would make every report less trustworthy.

GitHub REST

what changed

No per-caller version pin. Operations are deprecated in the specification and later removed, so the specification itself is the notice.

Stripe

what changed

Every account is pinned to a dated API version, so a specification change is an upgrade question rather than an outage. Findings here are worded as upgrade impact.

Twilio — deliberately not supported

Its api_v2010 specification did not change one operation in six months: 197 operations before, 197 after, nothing removed, nothing deprecated. Charging to watch it would be charging for nothing.

The part that costs money

The check is free and always will be — it runs on your machines and you can read every line of it. $49 per month, per organisation, buys the same check run daily against up to three manifests, and the report emailed to you, so a removal that lands on a Tuesday does not wait for your next build.

It is early access and priced as a proposal. There is no SLA, no real-time guarantee and no promise of complete coverage, and I would rather say that here than discover it with you later.

Open an issue to ask for the hosted version — that is the only contact channel, on purpose: it is public, it is where the tool lives, and it means your question and its answer are useful to the next person.