How do you stop an accidental breaking change to a JSON HTTP API from reaching production? Describe the automated checks you would put in a CI pipeline.

## Why review is not enough Breaking changes are usually accidents: a refactor renames a DTO property, a serializer config change starts omitting nulls, a validation annotation is tightened, an enum is converted to a stricter type. None looks like an API change in the diff. The defence has to be mechanical. ## Layer 1 — schema generation plus compatibility diff Make the API description a **build artifact**, generated from the running code (annotations, routes, DTOs), not a hand-written file that drifts. Store the last released version as a baseline; on every pull request, regenerate and diff. Classify the diff automatically. Fail on: removed path or operation, removed response property, narrowed type, new required request property, added enum value in a *request* the server now rejects elsewhere, removed response status code, changed error schema. Pass on: new operation, new optional request property, new response property. Emit warnings for grey-zone changes such as new response enum values so a human decides. This is cheap, deterministic, runs in seconds, and needs no consumers to participate. Its blind spot is everything not expressible in the schema. ## Layer 2 — consumer-driven contract tests Each consumer team writes tests against a mock of the provider and publishes the resulting **pact**: the requests it makes and the response fields it asserts on. The provider's CI replays every published pact against the real service. If the provider stops returning a field a consumer asserts, the *provider's* build goes red — before deployment, without a full integration environment. The strategic value is the inverse question. A schema diff tells you `legacy_id` was removed; the pact broker tells you nobody has read `legacy_id` for six months, so removing it is safe. That turns "we can never delete anything" into an evidence-based decision. The cost is organisational: it only works if consumers maintain their pacts and versions are tagged per environment so you know what is actually deployed. ## Layer 3 — semantic checks Units, meanings and defaults are invisible to both layers above. Guard them with provider tests that assert **concrete values** — a fixture whose `amount` is 1250 and whose `currency` is EUR, a default page size assertion, an assertion that an unknown id yields 404 and not 200-with-empty-body. When such a test fails, the change is intentional and needs a version or deprecation plan. ## Production evidence Instrument the edge: request counts per endpoint, per version, per client, and where feasible per response field consumed (via field-selection parameters, GraphQL-style projections, or SDK telemetry). This is the only source of truth about undocumented usage and it is what makes the sunset decision defensible. Pair it with a staging "chaos" mode that injects unknown fields and new enum values into responses, so intolerant clients fail during testing. ## Making it stick The gate must be blocking, with a documented, deliberately awkward override that records the justification and notifies consumers. If bypassing is easy, the check degrades into a warning nobody reads, and the first person to learn about the break is a customer.