why not just version API for breaking changes?
Great question. Versioning definitely helps, and most teams do version their APIs.
The problem I kept running into is that versioning answers “where do we put breaking changes?” but not “who is still using this?”
Hi HN,
I built this after breaking production APIs one too many times.
The problem was always the same: remove or change an endpoint, deploy, and a few hours later customers email saying their integrations broke.
API Impact Tracker answers one simple question before deploy:
"Which real clients will break if I ship this?"
It works by tracking which clients use which endpoints (via middleware),
normalizing paths (e.g. /users/123 → /users/{id}),
and comparing real usage with your OpenAPI spec.
Example output:
$ api-impact diff openapi.yaml
BREAKING CHANGE DETECTED
DELETE /users/{id}
Clients affected:
- acme-inc (used 2h ago)
- foo-app (used yesterday)
Design choices:
- Runs locally (SQLite) – no data leaves your infrastructure
- No SaaS, no phone-home
- Open source (MIT)
- CLI + GitHub Action
- Takes ~5 minutes to set up on an existing Express API
I'd love feedback, especially on:
1) API versioning and deprecations
2) GraphQL support
3) Other API-change pain points you've seen
Thanks!