Multi-source change detection
OpenAPI and GraphQL schema diffs, registry releases, published .d.ts diffs, changelogs and Deprecation headers. For vendors, a structured change manifest pushed straight to us.
Detection is live · fixes are next
Your integrations update themselves.
APIWatch tracks the APIs and SDKs you depend on, finds every call site touching a surface that's going away, and opens a pull request that typechecks, lints and passes your tests before you ever see it.
Read-only until you enable a repo. No PRs on the free tier.
Sunset Radar
Deprecated surfaces this repo actually uses
- aws-sdk-jsbreaking
SDK v2 end-of-support
Confirm date with vendor31 usages · 6 filesproduction - stripedeprecation
Charges API → Payment Intents
No shutdown date announced7 usages · 4 filesproduction - firebasedeprecation
Namespaced SDK → modular
No shutdown date announced12 usages · 3 files - openaideprecation
Pinned model identifier retiring
Check deprecations page2 usages · 1 fileproduction
Every date links to the vendor page it came from. Anything unconfirmed says so.
41 providers
Tracked at launch — Stripe, Twilio, AWS, Firebase, OpenAI, GitHub and more
Every deprecation on the radar links to the vendor page it came from.
Sunset dates are only shown when the vendor has published one. "Deprecated, no date announced" is a real and common answer, and we say that rather than inventing a date.
Nobody finds out until something breaks
The deprecation notice landed in a changelog you don't read, on a service the person who integrated it no longer works on.
The dependency isn't in your lockfile
A pinned API version string, a model identifier, an endpoint path in a fetch call. None of it is typechecked, none of it is in package.json, and none of it fails CI when the vendor turns it off.
Changelogs are noise by volume
Most releases are irrelevant. By the time you've filtered patch bumps for the fiftieth time, you've stopped reading — which is exactly when the breaking one arrives.
Finding every call site is the actual work
Grep finds the obvious ones. It doesn't resolve a client assigned to `this.stripe` in a constructor, re-exported through a barrel file, and called four modules away.
Detect, locate, fix
Three stages, and each one refuses to guess. Everything the PR claims is traceable to a spec diff or a changelog URL.
Usage detection that resolves
Member chains through construction, alias chains, destructuring, class properties, non-null assertions, barrel re-exports and CommonJS require. Raw HTTP too, with the URL normalised.
Codemods before models
A deterministic transform wherever a rule can express the change — testable, reviewable, fixture-backed. The model only gets involved where a rule genuinely can't.
A verification gate, not a hope
Typechecks, lints clean against your config, runs your test suite in a sandbox and stays under a diff ceiling. Fails any of it and the PR is never opened.
Honest about what it can't do
Behavioural changes and anything needing a business decision get an issue describing the options, not a PR. Being straight about that is what earns the right to open PRs at all.
Your source never leaves
We store symbol names, file paths and line numbers. No file contents, ever — there's no database field capable of holding them, and a test asserts it.
How it works
Install, index, watch. Fix generation is opt-in per provider.
- 1
Install the GitHub App
Installation-scoped, per repository, no personal access token. We read through the Git Trees API — for indexing there's no clone on disk at all.
- 2
We build a usage index
A cheap manifest and host prefilter runs first, so the ~95% of repos unaffected by any given change cost almost nothing. Only then does the AST work start.
- 3
You see the radar, then the PRs
Every deprecated surface you actually use, with its shutdown date. Turn on auto-PR per provider when you're ready — off by default, and never auto-merged unless you say so.
Vendor mode
Ship a breaking change without breaking your customers
White-label APIWatch and give your customers an update agent. When you release a breaking change, their codebases get pull requests automatically — branded as coming from you.
See what your customers actually use
Aggregate adoption per endpoint, per SDK method, per pinned API version. Most API companies genuinely do not have this, and it is valuable independently of the PRs.
Staged rollouts
Target a change to a cohort, roll out 5% → 25% → 100%, watch the merge rate, pause if it turns.
Your name on the PR
Logo, colours, PR author, custom domain. To the customer it looks like you shipped them a migration, because you did.
The boundary: Vendors see aggregated counts only. Never customer source, never file paths, never which repos. That boundary is enforced at the data layer — every vendor query ends in a $group, and a test asserts no call-site field can escape.
Launch
$2,000/mo
Up to 200 customer repos, adoption analytics, 5 campaigns a year
Scale
$5,000/mo
Unlimited repos, staged rollouts, custom domain, SLA
Enterprise
Custom
Plus services for the initial codemod rule library
Pricing
The free tier deliberately excludes pull requests. The PR is the value; the alert is the tease.
Company
$499/mo
Many repos, real compliance requirements.
- 100 repos
- SSO
- Audit log
- Self-hosted runner option
API vendors: see the vendor plans above — your customers' codebases update themselves when you ship a breaking change.
Questions people actually ask
No, and the limits are hard-coded rather than a setting we hope you find. At most 3 open APIWatch PRs per repo and 1 per provider. We only open PRs for breaking changes, security issues and deprecations with a sunset date — everything else is a digest line at most. Default posture is silence.
See what you're already depending on
Install on one repo, get the Sunset Radar, and find out how many deprecated surfaces are in your codebase right now. No PRs until you turn them on.
Install the GitHub AppFree tier, one repo, read-only. Uninstall in one click.