Bidirectional Contract
A contract verified from both sides — the consumer's expectations and the provider's actual behaviour — without either running the other's tests directly.
Consumer-driven contract testing requires the provider to run the consumer's expectations in its pipeline, which is organisationally demanding: a build failing because of another team's test.
Bidirectional contract testing relaxes that. The consumer publishes what it uses; the provider publishes its OpenAPI specification, verified against its own tests. A broker compares the two and reports compatibility.
The trade is honest: less rigorous, because the provider's specification is checked rather than its runtime behaviour, and a specification can be accurate while the implementation drifts. But adoption is far easier, and a provider that already maintains a verified specification adds nothing to its pipeline.
Either way, what makes contract testing valuable is the same: it captures what consumers actually depend on, not what the API offers. A field no consumer reads can be removed; a field one consumer reads cannot. Without that knowledge nothing is ever removed and APIs only accrete.
And either way, the mechanisms that make it operational are the same: version and environment tags, so verification runs against versions actually deployed rather than every version ever recorded; and can-I-deploy checks gating release on whether the combination about to ship is compatible with what is live.