What engineering teams told us about API changes.
Between 17 October and 1 November we asked engineers a simple question: when an API contract changes, can your team find every real downstream consumer, and coordinate the owners, before merge?
We reviewed 22 conversation threads between 17 October and 1 November 2026; 21 had replies, with follow-ups that varied by conversation. Here is what engineers told us about how they handle API changes today.
How teams manage API changes today
Paraphrases of private one-on-one replies, with no counts attached. Roles and employers are withheld; these were personal conversations, never company positions.
Version and migrate
Some replies described versioning, keeping older contracts working, and moving clients over before an old version is retired.
Watch who is calling
Some described using logs, dashboards and telemetry, or caller credentials and service IDs, to see which clients still use a version.
Coordinate across teams
Some described circulating changes to known consumers by email, or building in-house tooling to track downstream services.
Where it gets hard
A few replies pointed at the same limit: these approaches work best when the consumers are already known.
Blast radius is easy to miss
One reply said the people making or reviewing a change are often not aware of its blast radius.
Consumers are not always known
One reply said consumers can be unknown, with only the hits visible in monitoring.
Process leans on known lists
One reply described a process that relies on known consumers, with unidentified ones expected to flag their own dependencies.
Finding the consumer nobody registered is the gap Impact Gate works on. These are a small, self-selected set of conversations from the founder’s own network, not market statistics.
Want the detail? Read the full findings - every mechanism, pain point and pushback, anonymized.
See Impact Gate in action.
The demo runs on a bundled example project - no account needed. Connect GitHub to try it on your own repos.