Who StateAnchor is for

A short, honest self-selection guide. StateAnchor is a specific tool that solves a specific problem; if your team is not hitting that problem, there are better places to spend the budget.

When teams reach for StateAnchor

Five patterns reliably trigger adoption:

You hired a Head of Platform. API governance just became someone’s explicit responsibility. They need tooling that enforces the contract, not just a process doc.
You launched a partner program. External developers now depend on your contract staying stable. A breaking change reaches their production the same day you ship it.
You received an audit finding. SOC 2 or ISO 27001 reviewers flagged that you have no tamper-evident evidence trail for spec changes or breaking-change approvals.
You shipped a botched SDK release. A breaking change made it past review and customers felt it. The post-mortem asks: “how do we make sure this can’t happen again?”
You need to prove a change was reviewed. Compliance or security requires two-person approval before a breaking spec change ships. The current answer is a Slack message in a thread nobody can find.

Built for

Teams with APIs consumed by Claude Code agents, MCP clients, or autonomous systems. Agents surface drift as confidently wrong output, not as an error. Silent drift is more expensive than a loud one. If your API is in that loop, build-time enforcement pays for itself on the first incident it prevents.
Teams where SDK consumers are external— other companies, paying customers, partner integrators. A breaking change reaches their code the same day you ship it. The tamper-evident audit trail and share link matter here because you need evidence you can point at without logging anyone into your dashboard.
Solo founders and small teams who cannot afford a dedicated API governance role. The alternative to StateAnchor for a four-person team is “we will review it carefully in the PR.” That scales until the first missed deprecation. StateAnchor is the checklist you do not have to write down.
Teams already using Speakeasy or Fern for SDK / MCP generation who need enforcement, not another generator. StateAnchor sits upstream of whatever you use to generate the downstream artifacts — the gate fires before Speakeasy (or anything else) regenerates against a bad spec change.

Not built for

Internal-only APIs with a single consumer you control completely. If you own both sides of the contract and can coordinate a same-day refactor across the breakage, you do not need a gate. A grep in CI is fine.
APIs in pre-v1 flux. If you are still moving endpoints around weekly and your consumers are a handful of design partners who expect breakage, freezing the contract with a gate is friction. Revisit once the shape stabilises.
Teams who need a linter. Use Spectral. StateAnchor is not a style-rule enforcement tool and does not try to be — see Compare. Lint first, gate after.

How StateAnchor relates to the rest of the stack

Speakeasy / Fern build your SDK or MCP server from a spec. StateAnchor gates the spec change before those generators run. They are complementary, not competitive.
Spectral lints the spec for style rules (descriptions present, tags consistent, etc.). StateAnchor gates the spec for compatibility against your parent, merge-base, last known-good, and deployed baselines.
oasdiff / openapi-diff diff two spec files. StateAnchor runs four diffs simultaneously, classifies each finding, and produces an enforceable verdict.

If you are still unsure, the Compare page walks through the capability overlap and gap explicitly. If you have an internal API with two consumers and a weekly deprecation tolerance, you do not need StateAnchor yet. If you have agents calling your API in production, you probably do.

← Compare Quick start →

When teams reach for StateAnchor

Five patterns reliably trigger adoption:

You hired a Head of Platform. API governance just became someone’s explicit responsibility. They need tooling that enforces the contract, not just a process doc.

You launched a partner program. External developers now depend on your contract staying stable. A breaking change reaches their production the same day you ship it.

You received an audit finding. SOC 2 or ISO 27001 reviewers flagged that you have no tamper-evident evidence trail for spec changes or breaking-change approvals.

You shipped a botched SDK release. A breaking change made it past review and customers felt it. The post-mortem asks: “how do we make sure this can’t happen again?”

You need to prove a change was reviewed. Compliance or security requires two-person approval before a breaking spec change ships. The current answer is a Slack message in a thread nobody can find.

Built for

Teams with APIs consumed by Claude Code agents, MCP clients, or autonomous systems. Agents surface drift as confidently wrong output, not as an error. Silent drift is more expensive than a loud one. If your API is in that loop, build-time enforcement pays for itself on the first incident it prevents.

Teams where SDK consumers are external— other companies, paying customers, partner integrators. A breaking change reaches their code the same day you ship it. The tamper-evident audit trail and share link matter here because you need evidence you can point at without logging anyone into your dashboard.

Solo founders and small teams who cannot afford a dedicated API governance role. The alternative to StateAnchor for a four-person team is “we will review it carefully in the PR.” That scales until the first missed deprecation. StateAnchor is the checklist you do not have to write down.

Teams already using Speakeasy or Fern for SDK / MCP generation who need enforcement, not another generator. StateAnchor sits upstream of whatever you use to generate the downstream artifacts — the gate fires before Speakeasy (or anything else) regenerates against a bad spec change.

Not built for

Internal-only APIs with a single consumer you control completely. If you own both sides of the contract and can coordinate a same-day refactor across the breakage, you do not need a gate. A grep in CI is fine.

APIs in pre-v1 flux. If you are still moving endpoints around weekly and your consumers are a handful of design partners who expect breakage, freezing the contract with a gate is friction. Revisit once the shape stabilises.

Teams who need a linter. Use Spectral. StateAnchor is not a style-rule enforcement tool and does not try to be — see Compare. Lint first, gate after.

How StateAnchor relates to the rest of the stack

Speakeasy / Fern build your SDK or MCP server from a spec. StateAnchor gates the spec change before those generators run. They are complementary, not competitive.

Spectral lints the spec for style rules (descriptions present, tags consistent, etc.). StateAnchor gates the spec for compatibility against your parent, merge-base, last known-good, and deployed baselines.

oasdiff / openapi-diff diff two spec files. StateAnchor runs four diffs simultaneously, classifies each finding, and produces an enforceable verdict.