Contract Testing Tools: Pact, Specmatic & More

The tools fall into three groups that answer different questions, and most teams end up with one from each:

• Consumer-driven contract tools (Pact, Pact Broker and PactFlow, Spring Cloud Contract) ask: does the provider still give each consumer what it actually reads?
• Schema-first, spec-driven tools (Specmatic, Schemathesis, Dredd, Prism, Microcks and spec-driven platforms) ask: does the running provider match its published OpenAPI spec?
• Spec diff tools (oasdiff, openapi-diff, Optic) ask: is this change to the spec breaking for existing clients?

In this guide

1. How contract testing tools differ
2. Contract testing tools comparison
3. Consumer-driven contract testing tools
4. Schema-first and spec-driven contract testing tools
5. Open source and Java contract testing tools
6. How to choose a contract testing tool
7. Contract testing tools FAQ

How contract testing tools differ

Four questions separate the tools more than any feature list.

Where does the contract come from? Consumer-driven tools build it from consumer tests: each consumer records the requests it makes and the fields it reads, and that recording is the contract. Schema-first tools take a provider-owned OpenAPI (or AsyncAPI, GraphQL SDL, WSDL) document as the contract. Diff tools compare two versions of that document.

What does a green run prove? A passing Pact verification proves the provider satisfies every consumer that has published a pact. It says nothing about consumers that have not. A passing schema-first run proves the provider matches its spec. It says nothing about whether the spec covers what consumers depend on. A clean diff proves the spec change is backward compatible by the tool's rules, not that the implementation follows the spec.

Who has to adopt it? Consumer-driven tools need every consumer team to add a library, write interaction tests and publish to a broker. Schema-first tools need only the provider team and a complete spec. Diff tools need only a CI step.

What runs where? Some tools are libraries inside your test code (Pact, Spring Cloud Contract), some are CLIs pointed at a running service (Schemathesis, Dredd, Specmatic), some are proxies or mock servers (Prism, Microcks), and some are hosted services (PactFlow).

Contract testing tools comparison

This is the API contract testing tools comparison most teams need before a proof of concept. Capabilities are summarized from each project's documentation; check the current docs for your version.

Consumer-driven contract testing tools

Pact

Pact is the most widely used of the consumer-driven contract testing tools. The workflow has four steps:

1. The consumer writes interaction tests against a Pact mock provider, declaring the request it makes and only the response fields it reads.
2. Running those tests writes a pact file, a JSON document of interactions for that consumer-provider pair.
3. The pact is published to a Pact Broker or PactFlow, tagged with the consumer version and branch.
4. The provider verifies every relevant pact by replaying each interaction against a running instance, using provider states ("product 42 exists") to set up data, and publishes the result.

// order-service (consumer): what it needs from product-service
const { PactV3, MatchersV3 } = require('@pact-foundation/pact');
const { integer, string } = MatchersV3;

const provider = new PactV3({ consumer: 'order-service', provider: 'product-service' });

it('gets the price for an order line', async () => {
  await provider
    .given('product with ID 42 exists')
    .uponReceiving('a request for product 42')
    .withRequest({ method: 'GET', path: '/products/42' })
    .willRespondWith({
      status: 200,
      body: { id: integer(42), price: integer(2999), currency: string('USD') },
    })
    .executeTest(async (mock) => {
      const product = await getProduct(mock.url, 42);
      expect(product.price).toBe(2999);
    });
});

If product-service later renames price to unitPrice, its verification step fails and the provider's pull request goes red, before order-service ever calls the new version.

Strengths: language-agnostic contract format, contracts limited to what consumers actually use, mature tooling, and message pacts for event-driven interactions. Costs: every consumer team must adopt it, provider states need maintenance, and coverage is only as wide as the set of consumers that publish pacts.

Pact Broker and PactFlow

The broker is what turns Pact from extra tests into a release gate. It stores pacts and verification results per version, and answers can-i-deploy: is this version of this service compatible with everything already deployed to the target environment?

pact-broker can-i-deploy \
  --pacticipant product-service \
  --version "$GIT_SHA" \
  --to-environment production

The Pact Broker is open source and self-hosted. PactFlow is the commercial hosted broker from SmartBear, adding team management and bi-directional contract testing: the provider publishes its OpenAPI document (plus evidence it verified itself against it, from any tool), consumers publish their pacts, and PactFlow checks the pacts against the spec without replaying them against a running provider. That lowers the cost for providers that already test against their spec.

Spring Cloud Contract

Spring Cloud Contract puts the contracts in the producer's repository, written in a Groovy, YAML, Java or Kotlin DSL. From each contract it generates producer-side tests that verify the implementation, and WireMock stubs that are packaged as a stubs JAR and published to your Maven repository. Consumers pull those stubs with Stub Runner and test against them. A YAML contract, saved under src/test/resources/contracts/, looks like this:

description: should return product 42
request:
  method: GET
  url: /products/42
response:
  status: 200
  headers:
    Content-Type: application/json
  body:
    id: 42
    price: 2999
  matchers:
    body:
      - path: $.price
        type: by_type

Pact vs Spring Cloud Contract. Both implement consumer-driven contracts, but they optimize for different team shapes. Pact's contract is a language-neutral JSON file shared through a broker, which is the right fit once you have polyglot services: a Go provider with a JavaScript and a Java consumer can share one broker. Spring Cloud Contract gives a tighter loop for Spring shops (contracts, generated tests and stubs all come out of one build, and a broker is optional), but its stubs and generated tests are JVM artifacts, so non-JVM consumers fit less naturally. A practical rule: if every service in the relationship is Spring, Spring Cloud Contract usually wins; once a non-JVM service joins, Pact is the safer long-term format. Spring Cloud Contract can also read Pact contracts and work with a Pact Broker, which eases a later move.

Schema-first and spec-driven contract testing tools

Schema-first tools treat the provider's spec as the contract and test the running service against it. They need no consumer participation, which is why they scale to public APIs and large fleets. Their blind spot is the spec itself: if it documents only the 200 path, the tools will happily pass a service whose errors are undocumented. The mechanics of request and response validation are covered in API schema validation.

Specmatic

Specmatic turns an OpenAPI spec (AsyncAPI, gRPC and GraphQL need its commercial edition) into executable contract tests against the provider, and into stubs that consumers run against, so both sides test against the same document. It also checks backward compatibility between two versions of a spec, and encourages keeping specs in a central Git repository that both sides reference. It is the closest schema-first answer to Pact's "both sides test against one contract" model, without consumer teams writing interaction tests.

Schemathesis

Schemathesis reads an OpenAPI or GraphQL schema and generates many inputs per operation using property-based testing, then checks each response: server errors, status codes and headers not in the spec, and bodies that do not conform to the documented schema. It can also chain calls using OpenAPI links for stateful scenarios. It is strong at finding the inputs nobody thought to try, and weaker as a curated, readable regression suite.

Dredd

Dredd replays the examples in an API description document against your service and compares responses with them. It was built around API Blueprint and OpenAPI 2; OpenAPI 3 support is marked experimental, and the GitHub repository is now archived (read-only), so weigh that before adopting it for a new programme.

Prism

Prism, from Stoplight, is a mock server and a validating proxy. As a mock it serves responses from the spec's examples or schemas. In proxy mode it sits in front of the real service and reports any request or response that violates the spec, which adds contract checks to an existing functional suite without rewriting it.

Microcks

Microcks, a CNCF project, imports OpenAPI, AsyncAPI, GraphQL, SOAP and Postman artifacts, serves mocks from them, and runs conformance tests of a real endpoint against the same artifacts. It is a good fit for platform teams that want one self-hosted service for mocking and contract checks across many protocols. For more mocking options, see the best API mocking tools.

Spec diff tools: oasdiff, openapi-diff and Optic

These compare two versions of an OpenAPI document and classify each change as breaking or non-breaking: a removed endpoint, a new required parameter, a narrowed enum, a changed type. They do not touch a running service, so they are cheap to add to every pull request:

git show origin/main:openapi.yaml > /tmp/base.yaml
oasdiff breaking /tmp/base.yaml openapi.yaml --fail-on ERR

oasdiff is a Go CLI with a GitHub Action; openapi-diff from OpenAPITools is a Java library and CLI with HTML and Markdown reports; Optic adds linting and API-standards checks on top of diffing.

Where Shift-Left API fits

Shift-Left API is a schema-first, provider-side platform rather than a consumer-driven tool: there is no broker and no consumer pact workflow. It imports an OpenAPI or Swagger document (WSDL and GraphQL schemas too) and generates a test suite from it. A deterministic engine plans 79 scenario classes across 12 dimensions from the spec without needing an AI key, and generated tests carry field and type checks derived from each response schema. Two things matter specifically for contracts:

• Change detection with classification. Re-importing a spec diffs it against the project's current endpoints and labels each change breaking or non-breaking (a new required parameter, a removed success response, a narrowed enum, a type change). Changes wait for Approve & Import or Reject unless the project opts in to auto-approving non-breaking ones; approving creates new endpoint versions and does not edit existing tests.
• Drift checks on passing runs. A green run is still examined for responses that no longer match the documented contract: a missing required field, a changed primitive type or an undeclared enum value.

It also generates mock servers from the spec's examples and schemas for consumer-side testing, and runs in CI through first-party GitHub Actions, Jenkins and Azure DevOps integrations, or the public REST API from any other CI. Teams that need consumer-driven guarantees pair it with Pact for the relationships where a break is expensive. Details: API contract testing in Shift-Left API.

Open source and Java contract testing tools

Open source contract testing tools

You can build a complete contract testing workflow from open source contract testing tools alone:

• Consumer-driven: Pact libraries plus the self-hosted Pact Broker; Spring Cloud Contract for Spring.
• Provider against spec: Schemathesis, Dredd, Prism (proxy mode) or Microcks.
• Spec quality and diffs: Spectral for linting, plus oasdiff, openapi-diff or Optic for breaking changes.

What paid products add is mostly operational: hosting and upgrades (PactFlow vs a self-hosted broker), bi-directional checks, team management, and for platforms, generation and reporting so a team does not have to maintain the glue between five CLIs.

Contract testing tools for Java

Java has the deepest bench of contract testing tools:

• Pact JVM: JUnit 5 consumer tests and provider verification, with Spring and Gradle/Maven plugins.
• Spring Cloud Contract: producer-owned contracts, generated JUnit tests and WireMock stubs.
• Specmatic: runs on the JVM and fits Maven or Gradle builds.
• REST Assured with the json-schema-validator module, and the Atlassian swagger-request-validator to validate REST Assured or MockMvc traffic against an OpenAPI spec.
• openapi-diff for spec diffs in a Java build.
• Karate, which combines API tests, mocks and schema-style matching in one DSL.

A common Java setup: Spring Cloud Contract or Pact JVM between internal Spring services, the swagger-request-validator in provider tests for the public API, and openapi-diff in the build.

How to choose a contract testing tool

Selection criteria

1. Your contract source. If you maintain good OpenAPI specs, start schema-first; you already have the contract. If you have no specs but strong consumer test suites, Pact fits.
2. Who will adopt it. Consumer-driven tools need buy-in from every consumer team. If you cannot get that, schema-first plus diffs is the realistic baseline.
3. Languages. Polyglot fleets favour Pact's language-neutral pact files or spec-driven CLIs; all-Spring estates can take Spring Cloud Contract's tighter loop.
4. Release gating. If you deploy services independently and often, a broker with can-i-deploy (Pact Broker or PactFlow) or a mandatory breaking-change diff is what makes the results enforceable.
5. Protocols. Event-driven systems need AsyncAPI-aware tools (Microcks, or Specmatic's commercial edition) or Pact message pacts; SOAP and GraphQL narrow the field further.
6. Mocks. If consumers need to build before the provider exists, prefer tools that produce stubs from the same contract (Spring Cloud Contract, Specmatic, Prism, Microcks).
7. Operational cost. Self-hosting a broker, maintaining provider states and wiring several CLIs together is real work. Count it.

Pact vs OpenAPI: consumer-driven or schema-first?

This is the decision most teams actually face, and the two are not substitutes.

The usual failure of a schema-first programme is a spec that documents only 200, so every consumer's error handling is unverified and the suite is green anyway. The usual failure of a Pact programme is organizational: three of eleven consumers write pacts, and the provider believes it is protected.

A decision guide

• Public or partner API, one provider team: schema-first (Specmatic, Schemathesis, Prism or a spec-driven platform) plus a spec diff in every pull request.
• Internal microservices, polyglot, frequent independent deploys: Pact with a broker and can-i-deploy for critical pairs; schema-first verification for the rest. Consider PactFlow's bi-directional mode where providers already test against their spec.
• All-Spring estate: Spring Cloud Contract, plus openapi-diff for any externally published spec.
• Event-driven: AsyncAPI with Microcks or Specmatic's commercial edition, or Pact message pacts, and schema-registry compatibility rules.
• Large spec, little test code: a generator (Schemathesis, or a spec-driven platform) to get coverage across every operation, then curate.

A minimal consumer contract template

Whatever the tool, a consumer contract reduces to this shape. The rule that matters more than the JSON: include only the fields the consumer actually reads.

{
  "consumer": { "name": "REPLACE_WITH_CONSUMER" },
  "provider": { "name": "REPLACE_WITH_PROVIDER" },
  "interactions": [
    {
      "description": "a request for REPLACE_WITH_RESOURCE",
      "providerState": "REPLACE_WITH_PRECONDITION",
      "request": { "method": "GET", "path": "/REPLACE_WITH_PATH" },
      "response": {
        "status": 200,
        "body": { "FIELD_THE_CONSUMER_READS": "EXAMPLE_VALUE" },
        "matchingRules": { "$.body.FIELD_THE_CONSUMER_READS": { "match": "type" } }
      }
    }
  ]
}

A contract that mirrors the provider's full response is an integration test wearing a pact's clothes: it fails every time the provider adds a field the consumer never looked at, and teams learn to ignore it. For how a schema assertion in a tool like Postman compares with a real consumer contract, see Pact vs Postman for contract testing.

Contract testing tools FAQ

What are the best API contract testing tools?

It depends on the contract you have. For consumer-driven contracts, Pact with a Pact Broker or PactFlow is the most widely used option across languages, and Spring Cloud Contract suits JVM-only estates. For OpenAPI-first teams, Specmatic, Schemathesis, Prism and Microcks test a provider against its spec, and oasdiff or openapi-diff catch breaking spec changes in CI. Most teams combine one of each.

What are open source contract testing tools?

Pact and the Pact Broker, Spring Cloud Contract, Schemathesis, Dredd, Prism, Microcks, oasdiff, openapi-diff and Optic are all open source. Specmatic has an open-source core with commercial features, and PactFlow is the commercial hosted broker built on Pact. Open-source tools cover the whole workflow; paid options mainly add hosting, governance and bi-directional checks.

What tools support consumer-driven contract testing?

Pact is the main consumer-driven contract testing tool, with libraries for JavaScript, the JVM, .NET, Go, Python, Ruby, Rust and more, and the Pact Broker or PactFlow to share contracts and run can-i-deploy. Spring Cloud Contract also implements consumer-driven contracts for Spring and JVM services. Schema-first tools such as Schemathesis or Dredd verify a provider against its spec instead.

Which contract testing tools work with Java?

Pact JVM (JUnit 5 and Spring integrations), Spring Cloud Contract, Specmatic (which runs on the JVM), REST Assured with its JSON Schema validator module, the Atlassian swagger-request-validator, and openapi-diff for spec diffs. Karate also offers mocks and schema matching for Java teams. Pact JVM and Spring Cloud Contract are the two most common consumer-driven choices.

Should I use Pact or OpenAPI for contract testing?

They prove different things. Pact proves a provider still returns the fields a specific consumer actually reads; OpenAPI-based testing proves the provider matches its published spec, but not that the spec covers what consumers depend on. Use Pact for the few high-criticality consumer-provider pairs and spec-based verification everywhere else, or bi-directional contract testing to check one against the other.

Sources and further reading

• Pact documentation: consumer-driven contract testing, provider states and message pacts.
• Pact Broker: can-i-deploy: the deployment gate built on verification results.
• Spring Cloud Contract reference: contract DSL, generated tests and Stub Runner.
• Specmatic: specifications as executable contracts.
• Schemathesis: property-based testing from OpenAPI and GraphQL.
• Dredd: HTTP API testing against API description documents.
• Prism: OpenAPI mock server and validating proxy.
• Microcks: open-source mocking and contract testing.
• oasdiff and openapi-diff: breaking-change detection between OpenAPI versions.
• Optic: OpenAPI diffing and linting in CI.

Already have an OpenAPI spec? Start a free trial, import it, and get a schema-first contract suite plus a breaking-change review every time the spec changes.