Contract testing alternative: when Pact isn't enough (and what to use instead)

If you're weighing Pact or another consumer-driven contract framework, the honest answer is: it depends what you're actually trying to protect. Contract testing is excellent at one thing and structurally blind to another. This page lays out the line between them so you can tell which problem you have — and whether you need both.

What contract testing genuinely does well

Consumer-driven contract testing (Pact being the best-known) solves a real, specific problem: making sure a provider and its consumers agree on the shape of their interaction. The consumer declares the requests it makes and the responses it expects; the provider verifies it can satisfy them. Done well, this catches:

• A field a consumer depends on getting removed or renamed.
• A status code or content type changing out from under a client.
• A required request parameter quietly becoming mandatory.

For microservice fleets where many internal consumers integrate against shared providers, this is worth the investment. If that's your problem, use contract testing — Stoney isn't a replacement for it.

Where contract testing runs out of road

Contract testing has three costs and one blind spot that send teams looking for something else:

1. You have to write and maintain the contracts. Every expectation is hand-authored. Coverage equals whatever someone remembered to encode — which means the rules nobody thought to protect aren't protected.
2. It only covers consumers you control. Consumer-driven contracts need a consumer writing the pact. For a public API with external integrators, there's no consumer in your CI to drive the contract.
3. It tests shape, not rules.A response can pass every contract test and still violate a business rule: "free tier capped at 100 req/min" isn't a shape, so it isn't in the pact.
4. It can't tell you why a rule exists.A pact has no link to the ticket that authorized the behavior, so when something changes there's no trail back to intent.

The blind spot is the important one: the expensive incidents usually aren't shape breaks (those get caught). They're behavioral and rule-level breaks — and contract testing was never designed to see them.

The core difference, in one line

Contract testing protects the shapes you remembered to declare. A rule registry protects the business rules your API actually enforces — including the ones nobody wrote down.

One is a set of hand-authored expectations about structure. The other is a discovered, attributed list of the rules your service runs on, watched on every PR. They solve adjacent problems, and plenty of teams run both.

How Stoney approaches it differently

Stoney doesn't ask you to write contracts. It installs as a GitHub App and builds an API rule registry by correlating your code, your PRs, and your Jira tickets — then checks every PR against it before merge. The practical differences from contract testing:

• No authoring. Rules are synthesized from what your code already does, not hand-written. There are no pacts to maintain.
• Rule-level, not shape-level.It protects limits, caps, auth requirements, and retention windows — the behavioral rules a shape diff can't represent.
• Provenance built in. Each rule carries the ticket that authorized it and the PR that last touched it, so a change that contradicts intent surfaces for a human to resolve.
• Works for public APIs. No consumer needs to be in your CI for the rule to be watched.

If your problem is internal services agreeing on payload shapes, contract testing is the right tool. If it's "a change quietly broke a rule we promised and we didn't notice until a customer did," that's the registry's job.

Getting started

The free tier is enough to install the GitHub App, synthesize a registry from a real repo, and compare what Stoney finds against the contracts you'd otherwise hand-write:

1. Install the Stoney GitHub App on one repository.
2. Describe your product in one sentence to steer synthesis.
3. Review the rules Stoney discovered — including ones you never would have written a contract for.

See pricing or start free. For the full picture of what a registry is and why the category exists, read what an API rule registry is.