Why We Built SpecVault

It was a Tuesday deployment. The payments team had shipped a new version of their API — a clean refactor, they said, no functional changes. By Wednesday morning, three consumer teams had opened incidents. A required field had been renamed. An endpoint path had moved. The old spec was still in a Confluence page from eight months ago.

Nobody had updated it. Nobody had told the consumers. And nobody had a reliable way to compare the old shape against the new one. The whole incident took two days to fully resolve, and the root cause was a gap that every team with more than one service eventually hits: there was no single source of truth for what the API contract actually was at any given point in time.

The Slack-as-registry problem

We've seen this pattern at companies of all sizes. The "official" place to learn about an API is a Slack message from six months ago, a Confluence page that was accurate when it was written, or a README that someone remembers updating once. The OpenAPI spec — if there is one — lives in the repo and gets generated from code, but nobody's watching it for changes. Nobody's comparing v41 against v42 and asking: did any of these changes break someone?

Producer teams ship. Consumer teams adapt. When the adaptation fails, it's usually because the producer didn't know they broke anything, and the consumer didn't know to check.

Why existing solutions didn't fit

There are tools in this space. Stoplight, Swagger Hub, API Gateways with schema validation — but they're either too heavyweight for a small engineering team, require infrastructure buy-in to set up, or solve a slightly different problem (publishing API docs versus tracking contract changes between versions).

Consumer-driven contract testing tools like Pact are excellent but require producers and consumers to adopt the same toolchain and workflow simultaneously. Getting three teams to coordinate a Pact rollout is a project in itself. Meanwhile, the next breaking change ships.

We wanted something that took ten minutes to set up, required no changes to the producer's codebase or the consumer's toolchain, and gave both sides confidence that if a breaking change had happened, someone would be told.

The insight: version-aware diffing plus subscriptions

The core idea is simple: store every version of an API's OpenAPI spec, diff each new version against its predecessor using rules that match what consumers actually care about, and email the right people when something breaks.

Producers publish specs via a single curl command or a CI step. They don't need to annotate changes or write consumer tests. Consumers subscribe once per service. They don't need to modify their code or run new tooling. When a breaking change lands — a removed endpoint, a renamed required field, a new required parameter — the affected subscribers get an email before the change goes live in their environment.

What SpecVault is, and what it isn't

SpecVault is not a full consumer-driven contract testing platform. It doesn't run assertions against running services. It doesn't generate test stubs. It's a registry and a diff engine, and that's intentional. The goal is to make the cost of "API contract visibility" low enough that every team actually has it, rather than high enough that only the teams with dedicated platform engineers bother.

It's a fully hosted service — nothing to install, deploy, or maintain. We run, scale, and back it up for you. If you have an OpenAPI spec, you can sign in and be set up in under ten minutes.

We built SpecVault because we kept hitting this problem and the existing tools required too much commitment for too little return. If you've ever found out about a breaking API change from a production incident rather than a colleague, this is for you.