api-verity-lab¶
API contract governance in one tool: breaking-change rules, runtime drift detection, schema-driven fuzzing, traffic replay and performance budgets — for OpenAPI, Swagger 2.0, AsyncAPI, GraphQL, gRPC, MCP tool manifests and WSDL.
Every supported spec format compiles into one normalized contract model, and every engine downstream reads that model rather than the original document. That is what lets a breaking-change rule, a fuzz generator and a drift check agree about what an operation is.
Generated by scripts/record_demo.py from real runs against fixtures/,
and re-checked in CI.
Start here¶
| If you want to | Read |
|---|---|
| Start from the format you have | OpenAPI · AsyncAPI · GraphQL · gRPC · MCP · SOAP |
| Compare it with what you already use | oasdiff · Schemathesis · Spectral · Pact · Buf · all of them |
| Try it without installing anything | Playground |
| Understand the design | Architecture |
| Know which rule fired, and why | Rule catalog |
| Know what each format supports | Spec support · Protocol support |
| Gate a pipeline on contract changes | CI contract gate |
| Run a multi-step workflow, or read one somebody else wrote | Workflow authoring · Arazzo |
| Ask at what rate a service stops coping | Load shapes |
| Serve a stack of mocks reproducibly | Virtualization workspaces |
| Use it as a library | SDK |
| Branch on results in a script | Exit codes |
| Judge whether it is ready for you | Capability status · Product gaps |
What this project promises about its own output¶
It is a verification tool, so one class of bug matters more than the rest: the tool asserting something it did not establish. Three habits follow, and each is enforced in CI rather than intended.
- Never assert what the run did not establish. A field that cannot be
derived reads
unknown, with a reason. Provenance in an artifact that gates someone else's build has to be earned. - Documented output is captured, never written. The examples in the README come from real runs; the rule catalogue is generated from the code; the competitive table is rendered from committed API data. CI fails when a generated file and its source disagree.
- Counts are derived. Rule totals, command counts and page counts come from the source, not from prose that was true once.
The rule catalog is generated by
scripts/generate_rule_catalog.py. The
competitive analysis is rendered by
scripts/generate_competitive_table.py from data fetched by
scripts/fetch_competitor_meta.py. If either disagrees with its source, the
build fails.