Roadmap | Apiweld

What each release delivered, how we tested that it works, and the design decisions that are settled.

Apiweld was built in four releases, each usable on its own. All four have shipped as of 0.4.

v0.1 Weld: add a client

Search a catalog of APIs, pick endpoints, and generate a typed client into your repo. This release includes the Go engine, the catalog, the slicer, the lockfile, and the init, search, show, add, remove, and generate commands, plus the matching MCP tools.

Done when an agent can go from “I need to create a Stripe refund” to a typed, committed, two-endpoint client without leaving the chat.

v0.2 Watch: detect drift

apiweld check fetches the latest spec, skips changes to endpoints you don’t use, and labels the rest breaking, risky, or safe. --fail-on makes it a CI gate, and reports are written as JSON and Markdown. apiweld update applies safe changes when your policy allows it. The MCP server gains check_drift.

Done when replaying a real Stripe or GitHub spec history against a test project reports exactly the changes that affect the selected endpoints, and nothing else.

v0.3 Heal: fix breaking changes

apiweld heal regenerates the client in a separate worktree, runs the TypeScript compiler to find the call sites that break, and writes a plan. heal --apply and verify let an agent fix those call sites until everything passes. The MCP server gains get_heal_plan and verify, and a GitHub Action runs the check on a schedule and opens a pull request.

Done when a breaking test change produces a plan whose call sites match the compiler errors, and an agent can fix them until verify passes.

v0.4 Widen: more sources, languages, and signals

Runtime drift: generated Zod validators log responses that don’t match the spec, without blocking them.
wellknown: sources that read a provider’s RFC 9727 API catalog.
Your own catalogs, configured in ~/.apiweld/settings.json.
A second generator: Go clients with oapi-codegen.
Autocomplete for operation names in apiweld.config.ts.

Settled decisions

These choices are made. New work should follow them.

Native engine binaries. A single WebAssembly build might be explored later. It won’t replace the native binaries by default.
Diff the full spec, then filter. Filtering findings after the diff keeps oasdiff’s attribution for shared schemas. Slicing before the diff is only a fallback for specs too large to diff whole.
Commit generated code. It’s reviewable and agents can read it. outputHash catches hand-edits. Generating on install isn’t supported.
Compact signatures by default. describe_operation and apiweld show expand nested types only when asked (--depth).
Edit the config only when it’s safe. If the config is too dynamic to edit reliably, print the snippet and let the agent or a person apply it. Never guess.

How it relates to other tools

APIs.guru is the seed for the public catalog (CC0). Apiweld fetches from the provider’s own URL when the directory records one.
Hey API generates the TypeScript code. Its hosted platform serves API providers publishing their specs. Apiweld is for the teams consuming third-party APIs.
oasdiff does the diffing and breaking-change rules.
Hosted migration services turn spec changes into pull requests, but run on someone else’s servers and don’t help you find APIs.
Runtime tool platforms such as Composio let agents call APIs while they run. Apiweld works at build time: it produces code that ships with your app and runs without an agent.