API Impact Tracker – Know which API clients you'll break before deploying

mickle00 · 2026-01-11T20:52:05 1768164725

why not just version API for breaking changes?

PeterDS · 2026-01-11T21:10:12 1768165812

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?”

PeterDS · 2026-01-11T20:25:19 1768163119

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!