Guides and comparisons
Guides on API breaking change alerts, comparisons with oasdiff, Optic, Bump.sh, Pact and Specmatic, and how Graphwake scores the impact of a change.
Comparisons and alternatives
- CompareCompare API breaking change toolsoasdiff, Optic, Bump.sh, Pact, Specmatic and Graphwake side by side: what each one checks, who it tells, and whether it blocks a merge. Pick the comparison that fits your setup.
- Compareoasdiff vs Graphwakeoasdiff finds breaking changes in OpenAPI specs. Graphwake also knows who consumes each endpoint, scores the impact, and alerts only those teams.
- AlternativesLooking for an Optic alternative?Optic’s GitHub repository was archived in January 2026. Here is what to use for OpenAPI breaking-change checks, and what Graphwake adds: alerts to the teams that consume each endpoint.
- AlternativesLooking for a Bump.sh alternative?Bump.sh publishes API docs and changelogs. If what you need is to tell the specific teams affected by a breaking change, here is how Graphwake differs and when to use each.
- Alternativesoasdiff alternatives for API breaking changesAn honest roundup of tools for OpenAPI breaking changes: oasdiff, Optic, Bump.sh, Pact, Specmatic and Graphwake, sorted by the question each one answers.
- ComparePact vs GraphwakePact tests integrations with code-first contract tests. Graphwake alerts the consumer teams of an endpoint to breaking OpenAPI changes. When to use each, and when to use both.
- CompareSpecmatic vs GraphwakeSpecmatic turns API specs into executable contract tests and a compatibility gate. Graphwake alerts the teams that consume an endpoint. How they differ and when to use both.
- Compareoasdiff vs Opticoasdiff and Optic both diff OpenAPI specs for breaking changes. Optic’s repository is archived; oasdiff is maintained. What each does, how to move, and who tells the consuming teams.
- ComparePact vs SpecmaticPact checks what each consumer uses, from consumer tests. Specmatic turns your API spec into tests and a compatibility check. Where each one stops a break, and who hears about it.
Guides
- GuideAPI breaking change alerts: how to tell the right teamsDetecting an API breaking change is a solved problem. Telling the teams that depend on it is not. Three routing models, their trade-offs, and what to do between teams in one company.
- GuideHow to notify consumers of API changesWhy email, changelogs and #general fail between teams in one company, what to do instead, and a copy-paste notice template for a breaking API change.
- How it worksHow the 0-100 impact score is builtHow Graphwake scores a change set from 0 to 100: points per breaking change, affected team, person notified and blind spot, with caps and the Low, Medium and High bands.
- GuideAsk your AI assistant who breaks before you change an APIConnect Graphwake MCP to Claude Code, Cursor or VS Code with GitHub Copilot, then ask who consumes an endpoint and check your local OpenAPI spec before you push.
- GuideOpenAPI breaking changes: a reference with examplesWhich OpenAPI changes break clients and which do not, each with a before/after YAML snippet and the oasdiff rule ID it triggers. Includes the cases where tools disagree.
- GuideAn API breaking change checklist for pull requestsA reviewer checklist for pull requests that change an OpenAPI spec, plus a copyable PR template: what to check in the diff, who calls the endpoint, and who to tell before merge.
- GuideThe oasdiff GitHub Action, step by stepSet up the oasdiff GitHub Action step by step: the workflow, each input, how fail-on decides the build, where the output appears, and what to do with each breaking change it finds.
- GuideOpenAPI diff in CI that never blocks the buildRun an OpenAPI breaking-change check in GitHub Actions or GitLab CI that reports on every pull request and never fails the pipeline, plus the questions a security review will ask.
- GuideAPI change notifications in Slack and Microsoft TeamsWhat a good API change alert says (what, who, severity, action), sample messages for Slack, Microsoft Teams and email, and how to wire each one after the Teams connector retirement.
- GuideAPI dependency map: how to know who calls whatWhat a team-level API dependency map holds, how it differs from a gateway, tracing or catalog map, and when a gateway, tracing or catalog map is the better tool.
- GuideAPI consumer tracking: four ways to know who calls an APIFour ways to know who calls an API: gateway keys, access logs, distributed tracing and declared subscriptions. What each one sees, what it costs, and where each one fails for internal APIs.
- GuideHow to find which teams use an API endpointNo gateway, no tracing, and you need to know who calls one endpoint. Search the code, read the access logs, ask the right channels, and write the answer down so nobody repeats the hunt.
- GuideHow to deprecate an API endpoint safelyA checklist for retiring an internal API endpoint: name an owner, find every consumer team, give notice, send Deprecation and Sunset headers, prove the traffic is gone, then remove it.
- GuideOrphaned API endpoints: what they are and how to find themAn orphaned API endpoint has no consumer team on record; an unowned one has nobody to answer for it. How to find both from your OpenAPI specs, and a weekly routine to clear them.
- GuideAPI governance when many teams share APIsAPI governance for companies where teams call each other’s APIs: three written rules (ownership, change policy, notification), what enforces each, and when a linter, catalog or gateway is enough.
By role
- For teamsGraphwake for engineering leads: who owns, who calls, who breaksWhich team calls which API, who owns it, which endpoints nobody uses, and who breaks if one changes. How engineering leads answer these from their OpenAPI specs with Graphwake.
- For teamsGraphwake for platform and API governance teamsA dependency map consumer teams keep current themselves, a breaking-change check on every pull request, and alerts that reach only the affected teams. Setup for platform teams.
- For teamsGraphwake for teams that call other teams’ APIsYour app calls another team’s API. Subscribe to the endpoints you use and hear about breaking changes in your own channel, often while the change is still a pull request.
Opinion
- OpinionDoes your AI coding assistant know who uses your API?Your assistant reads your code. It can’t read the other team’s. Why the map of who calls an endpoint has to come from somewhere else, and where it can come from.
- OpinionStop announcing API changes in a shared Slack channelA shared channel for API changes reaches everyone and gets read by no one. Right people, not more people: send each change to the teams that call the endpoint.