Recognise API changes that break real consumers
A change can look small in code while forcing every consumer to update. These are the contract edits that deserve an automated compatibility gate.
Removing an endpoint or response
Deleting an operation or a response status that clients handle removes behaviour they may already depend on and is normally breaking.
Making an input required
Adding a required query parameter, header or request property breaks clients that continue sending requests in the old shape.
Narrowing a response schema
Removing a response property, changing its type or restricting an enum can break deserialisation and downstream business logic.
Separating compatible additions
New optional inputs, additional endpoints and additive response capabilities can usually ship without forcing existing consumers to change.
Protect every pull request automatically
Install the GitHub App, choose a repository and get a clear pass or fail status whenever its OpenAPI contract changes.
Frequently asked questions
Is adding a new endpoint breaking?
No. A new independent endpoint does not remove behaviour used by existing clients.
Is adding an optional property breaking?
It is commonly compatible, although strict consumers should still be designed to tolerate additive response fields.
Is changing an enum breaking?
Removing an allowed value is breaking. Adding a response enum value may also affect clients that assume the set is exhaustive.
How can teams catch these changes?
Compare the base and proposed OpenAPI documents automatically on every pull request and require the compatibility check before merge.