TypeScript-first SDK release control

Ship SDK changes with evidence, not guesswork.

Beautiful TypeScript SDKs, Python clients, and MCP servers, generated from one OpenAPI source. Every release ships with a typed compatibility report your reviewers, CI, and coding agents can all read.

Start a release review

Release room

Spec, SDK, diff, and agent status in one view.

Ready

Release confidence98%

Major breakages0

Review packet1

Release confidence98%

Artifact	Status	Owner
OpenAPI graph	normalized	core
TypeScript manifest	extracted	runner
Compatibility diff	reported	review

Release proof

Every report ships with the same typed evidence. Runs, manifests, diffs, decisions.

{
  "release": "v1.4.0",
  "sdk": "typescript",
  "semver": "minor",
  "manifest": "12 symbols",
  "diff": "1 review, 0 major",
  "agent": "dry-run",
  "next": "approve"
}

Built for modern release surfaces

OpenAPITypeScriptGitHubCI gatesMCP agentsnpmWebhooksSlack

Platform

Everything reviewers need before an SDK release moves.

Spec to SDK evidence

Normalize OpenAPI changes, extract SDK surfaces, and show the exact compatibility impact before release.

Overlay review

Keep naming, pagination, resources, and error decisions explicit instead of burying them in generated code.

Agent-safe execution

Expose dry-run MCP and Code Mode workflows with typed contracts, redaction, and audit output.

Release operations

Give product, SDK, and platform teams one room for runs, reports, billing gates, and reviewer signoff.

Why SDK Parity

Replace tribal review with a typed release contract.

What changes vs the status quo

Every layer of the release loop ships with structured output, not eyeballed logs.

Capability	Hand-rolled review	Generic codegen	SDK Parity
Normalized API graph diff	Not covered	partial	Built in
Public SDK surface manifest	By hand	Generator-specific	Typed and stable
Compatibility recommendation	Best guess	Not covered	Semver + evidence
Agent dry-run path	Not covered	Not covered	Typed MCP contract
Reviewer-ready packet	Slack thread	Build logs	One report

Workflow

Connect, extract, compare, approve — without leaving the report.

Release workflow

A narrow path from API change to SDK release evidence.

01
Connect
Point SDK Parity at an OpenAPI source, repo, or CI artifact.
02
Extract
Build a TypeScript SDK manifest from the generated surface.
03
Compare
Diff previous and candidate manifests against the normalized API graph.
04
Approve
Ship with a review packet that humans, CI, and agents can inspect.

Artifact map

Every layer has a typed output.

Layer	Input	Output
Source	OpenAPI	operation graph
SDK	TypeScript	surface manifest
Review	Compatibility	semver recommendation
Agent	MCP dry-run	typed tool result
Platform	Billing gate	usage and entitlement

Agent DX

Let agents inspect SDK state before they propose code.

Typed output

{
  "sdk": "typescript",
  "semver": "minor",
  "majorBreakages": 0,
  "addedSymbols": 4,
  "removedSymbols": 0,
  "agentWrites": "dry-run",
  "nextAction": "approve"
}

json

Built for coding agents

A typed contract for every dry-run, manifest, and review packet.

SDK Parity exposes conventional contracts for search, dry-run execution, artifacts, and redacted audit events so coding agents work inside product boundaries.

Search across runs, manifests, and reports
Dry-run any tool before a write is proposed
Stable IDs, scopes, and audit events

Security by default

Redaction, validation, and dry-run guardrails.

Redacted events
Scoped actions
Typed boundaries
Release evidence

Release risk made visible

Catch breaking SDK changes before users find them.

Reviewers get the same structured report every time: what changed, what generated, what broke, and what an agent is allowed to do next.

FAQ

Answers before you connect a spec.

Do I have to host the runtime?

No. Start with the CLI for local audits, then move to hosted runs once your team needs shared history, gates, or agent access.

Which SDK languages are supported?

TypeScript is the first-class surface today. Other languages are added once the compatibility model is proven against TypeScript releases.

How does agent execution stay safe?

Agent calls run as typed dry-runs first. Every planned write is declared, redacted, and reviewable before any mutation reaches your code or releases.

Can I gate releases in CI?

Yes. Reports emit stable JSON that CI workflows, release scripts, and review bots can read. Failing semver rules block merge by design.

What does pricing follow?

Plans bill per project, not per seat. Usage credits cover audit, generation, and publish dry-run runs so reviewable work is the unit you pay for.

Review faster

Bring SDK review into the same loop as API review.

Start with a TypeScript release audit, then grow into hosted runs, overlays, and agent-safe workflows.

Start now