Technically breaking: removing an endpoint, operation, field or enum value; renaming any of them; changing a field’s type; making an optional request parameter required; adding a new required parameter; tightening validation so previously accepted input is rejected; changing a default; changing status codes or error shapes; changing pagination or sort behavior; changing authentication or required scopes.
Most of these can be detected mechanically by diffing your OpenAPI against the previous version in the pipeline. If you do only one new thing this quarter, do that — it moves breaking-change detection from “we hope someone notices in review” to “the build says no.”
But there is a second category that no diff will catch and that matters just as much to the business: changes in behavior, semantics, performance, rate limits, pricing, terms, or data completeness. If a field still exists but now returns null for half your consumers, nothing in the contract changed and everything in practice did. If you cut the rate limit by ninety percent, you broke people without touching the schema.
That is why breaking changes are a business question and not only an engineering one. The test that actually matters is simple: would a consumer who did nothing suddenly find their integration behaving differently? If yes, treat it as breaking, whatever the diff says.
