The package manager for API contracts.
No services. No infra. Just two files.
Specs are code.
Manage them like it.
Declare your API specs, pin your dependencies, catch breaking changes before they ship — using git as the registry and a lock file for reproducibility. Think go mod, but for OpenAPI and AsyncAPI.
▸ hover to pause · auto-cycles through add → check → generate
What it looks like
Two files. That's the footprint.
Apigraph adds apigraph.yaml (your service's API identity) and apigraph.lock (pinned dependencies). Both live in your repo root, next to your code. ~5 minutes to add to a repo.
Commit both files. Every teammate and CI run resolves the exact same spec versions.
The big picture
Every edge, intentional.
Every dependency is pinned. Every impact is visible. Click a spec version to see who depends on it — and who breaks if it changes.
The problem
Your API specs are unmanaged dependencies.
Teams hand-copy specs into Slack, pin nothing, and discover breakage in production. The same problem package managers solved for code — nobody solved for API contracts. Until now.
01
No inventory
Teams don't know which API specs exist across the org. Specs live in wikis, repos, Notion pages — everywhere except somewhere queryable.
02
No dependency graph
Nothing tracks which service consumes which contract. When a spec changes, nobody knows who breaks.
03
Silent breakage
Breaking changes ship undetected. Fields get removed, types get changed, and the first alert is a 500 in production.
04
Drifting clients
Hand-written client code diverges from the spec it was built against. The types say one thing, the API returns another.
How it works
Three commands. Full contract lifecycle.
Your specs stay in your repos. No central service required. Git is the registry, semver tags are releases.
DECLARE & PIN
apigraph init · apigraph add
Define your service's API identity, then add dependencies on other services' specs. Every version is pinned in a lock file. Every build is reproducible.
→ apigraph.yaml + apigraph.lock
DETECT
apigraph check
Field-level breaking change detection for OpenAPI and AsyncAPI. Removed fields, type changes, new required parameters — caught in CI, not production.
→ 3 consumers affected
GENERATE
apigraph generate
Typed clients from the exact spec version in your lock file. Apigraph doesn't replace your generator — it ensures the spec it runs against is correct, versioned, and reproducible.
→ lib/generated/apigraph/
OBSERVE
Consumer dependency graph
An optional proxy watches which services fetch which specs. Over time it builds a live dependency graph — passively, without anyone declaring anything. When a breaking change lands, you already know who's affected.
→ apigraph graph --impacted
In your CI pipeline
One step. Breaking changes fail the build.
If a spec change breaks consumers, the build fails and apigraph check lists exactly which fields changed and who is affected.
The difference
What changes when you adopt apigraph.
Early access
Stop shipping breaking changes.
Start pinning your specs.
Apigraph is in private development. Send an email and you'll be in the next cohort — no forms, no newsletters, a real reply from a real person.
pavel@apigraph.dev · usually replies within a day