Contract testing is four jobs, not one, and two of them are already free

A developer renamed a response field from `customer_id` to `customerId` to match the rest of his codebase, every test passed, and review approved it in about four minutes ^[1]. Three days later a mobile team filed a P1, because their client had been reading `customer_id` for eighteen months ^[2].

Nothing in the pipeline was broken, according to his account published on dev.to: the tests tested his own code, and his code was fine, while nothing in CI was looking at the contract with anyone else ^[3]. His argument, and it is the useful part of the post, is that "contract testing" is one phrase covering four unrelated problems, and that separating them makes the tool question mostly go away ^[4].

Job one is a diff: compare two OpenAPI specs, classify the changes, and flag the backwards-incompatible ones, such as removed endpoints, narrowed types, and newly required request fields ^[5]. Job two is linting: missing descriptions, inconsistent casing, absent `operationId`, auth described in ways that bite later ^[6]. Job three is different in kind, namely whether a change breaks a named consumer, since removing an endpoint nobody calls is free while removing one three teams depend on is an outage ^[7]. Job four is organisational: someone has to decide a finding blocks a merge, and someone has to be able to override it without switching the check off ^[8]. He notes that most tools do one or two of these well and none do all four, his own included ^[9].

Once the jobs are split, the cheap part is obvious. oasdiff is open source, carries several hundred breaking-change checks, ships a CLI and a GitHub Action, and offers a hosted web diff ^[10]. He calls it the reference implementation and says that if the requirement is knowing when a pull request breaks the spec, install it and skip the rest of the post ^[11]. He goes further, calling breaking-change detection commoditised table stakes that nobody should pay for as a standalone feature, his own product included ^[12]. Linting is similarly settled: Spectral is the de facto standard, vacuum is a faster Go implementation that reads the same ruleset format, and both are free ^[13], while Stoplight, Apigee API hub and Azure API Center all bundle Spectral already ^[14]. That puts two of the four jobs at zero licence cost ^[1].

The failure mode there is not the linter but what happens to its output. He reports watching this at two companies: `spectral lint` prints a wall of warnings, someone wires it into CI, it fails on 200 findings on day one, and by week three the command ends in `|| true` ^[15].

Job three is where paying starts to make sense. Pact and PactFlow have consumers publish what they actually use and providers publish what they offer, with a broker ruling on whether a given pair is compatible ^[16], and `can-i-deploy` answers whether a specific build will break a consumer that is live right now ^[17]. PactFlow starts around $99 a month ^[18], which is roughly $1,188 a year ^[2]. The reason to pay is the hard limit of spec-to-spec comparison: it cannot tell you a consumer reads a field it never declared, and runtime pact verification can ^[19].

Job four is the one nobody has finished. The author, who discloses he wrote SpecShield and says teams that only need what oasdiff does should use oasdiff ^[22], weights governance findings by severity into a 0-100 score and an A-F grade, with any error-severity finding capping the grade at C ^[21]. The mechanism matters less than the premise: a number a team has agreed on is easier to defend at a deadline than a list.

Two things to watch. Optic was archived in January 2026 and is now unmaintained, which he says surprised several people he spoke to ^[20]. And check whether your own lint step still ends in `|| true` ^[15].