Background
We recently identified an issue through an inconsistency in the number of records returned in an API response. This allowed us to notice, after the fact, that a fix had been applied that changed the behavior of an existing API.
Problem
We understand that information about resolved bugs is eventually made available (e.g., in known-issue lists or patch notes). However, this is only a means of retrospective confirmation — it does not allow customers to become aware of a change before it is applied.
This is a significant concern for fixes that affect the specification or behavior of API responses. If a future fix changes the meaning or format of a returned value without causing an obvious processing error (i.e., the call still completes "successfully" but the returned data means something different), our systems would have no way to detect that anything changed. We could continue operating on the old assumptions, make incorrect downstream decisions, and only discover the problem much later — or never.
In our recent case, we were fortunate that the change surfaced as a clear anomaly (a record-count mismatch). We do not believe it is acceptable for silent, behavior-changing fixes to be discoverable only after an error occurs downstream.
Request
We would like to request a mechanism for individual or advance notification to affected customers — prior to a patch/fix being applied — specifically for changes that affect API response specifications or behavior. This would allow customers to review and prepare for the impact ahead of time, rather than discovering it reactively through production errors.
