---
title: "Roadmap"
description: "What each release delivered, how we tested that it works, and the design decisions that are settled."
---

> Documentation Index
> Fetch the complete documentation index at: https://apiweld.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Roadmap

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](https://www.rfc-editor.org/rfc/rfc9727) 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.

1. **Native engine binaries.** A single WebAssembly build might be explored later. It won't replace the native binaries by default.
2. **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.
3. **Commit generated code.** It's reviewable and agents can read it. `outputHash` catches hand-edits. Generating on install isn't supported.
4. **Compact signatures by default.** `describe_operation` and `apiweld show` expand nested types only when asked (`--depth`).
5. **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](https://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](https://heyapi.dev)** generates the TypeScript code. Its hosted platform serves API providers publishing their specs. Apiweld is for the teams consuming third-party APIs.
- **[oasdiff](https://www.oasdiff.com)** 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.

Source: https://apiweld.dev/roadmap/index.mdx