A platform has many internal services and many external API consumers. Where does contract testing apply, and what replaces it where it cannot?

Where it applies

Internal consumers, where both parties can participate. Each consumer declares what it needs — the fields it reads, the values it depends on, the errors it handles — and the provider verifies every consumer's contract in its own pipeline without either party running the other's code.

That makes compatibility a build-time property rather than an integration-time discovery, and it scales with consumer count where combinatorial integration testing cannot.

What it catches and misses

Catches: removed or renamed fields, changed types, changed error shapes, a field that stopped being populated — the overwhelming majority of real breakages.

Misses: semantic changes where the shape is identical and the meaning is not — a status code that now means something different, an event that now fires at a different point. Nothing automated catches these, and they need versioning discipline and documented semantics. Also misses performance regressions and emergent cross-service behaviour.

What replaces it for external consumers

Recorded traffic replay. Run real captured requests against the new version and diff the responses. It requires nothing from the consumer, it reflects actual usage rather than declared usage, and it catches behaviour changes that a declared contract would not have covered.

Its weakness is that it only covers what has been observed, so a rarely-used endpoint is untested — which argues for retaining a small set of explicit contract tests for the critical paths.

The requirement that makes either work

Per-consumer, per-field usage telemetry. Without knowing who reads what, a provider cannot assess a change and therefore does not make one — which is the coupling the architecture was supposed to remove, in a less visible form.

The practical requirements

Contracts generated from the consumer's actual tests rather than written separately · provider verification blocking the provider's build · a versioned shared contract store so retired consumer versions stop being verified · and a small end-to-end suite retained for the handful of journeys where the cost of being wrong is highest.