3 comments

  • mickle00 3 hours ago

    why not just version API for breaking changes?

      PeterDS 3 hours ago

      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 3 hours ago

    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!