Open source · runs locally · built for coding agents
Like shadcn/ui, but for APIs.
Pick the endpoints you need from any public API. Apiweld writes a typed client for just those into your repo, as code you own instead of an SDK you install. When the provider changes something you call, it shows you which lines break.
terminal
or ask your agent
$ npx apiweld search "refund a payment" --ops
stripe POST /v1/refunds Create a refund
$ npx apiweld add stripe PostRefunds GetRefundsRefund
Welded stripe: GET /v1/refunds/{refund}, POST /v1/refunds
Import from ./src/apis/stripe
$ npx apiweld check
stripe: no driftapiweld.config.ts
committed
import { defineConfig } from "apiweld";
export default defineConfig({
output: "src/apis",
generator: { name: "hey-api", client: "fetch", validators: "zod" },
apis: {
stripe: {
source: "https://raw.githubusercontent.com/stripe/openapi/master/latest/openapi.spec3.json",
operations: [
"POST /v1/refunds",
"GET /v1/refunds/{refund}",
],
policy: { autoRegenerate: "safe" },
},
},
});Calling a third-party API is still guesswork
Coding agents write integrations in seconds. Most of them end up in one of three places.
The agent writes fetch from memory
Field names come from training data, not the current spec. Nothing is typed, so a renamed field or a missing parameter shows up in production, not in the editor.
The vendor SDK is the whole API
You install hundreds of endpoints to call three. Many APIs have no TypeScript SDK, or one that trails the spec by months. And the SDK is a dependency you can't read or change.
Nobody tells you when the API moves
Providers rename fields, tighten enums, and drop endpoints. A version bump or a changelog tells you something changed. It doesn't tell you which lines of your code break.
Own the client, not a dependency
shadcn/ui showed that you don't need a component library in node_modules. A CLI copies the components you use into your project, and you own them from then on. Apiweld does the same for APIs.
Stripe's spec has more than 600 operations. A refund flow needs two. Apiweld generates those two, with their types and Zod validators, into a folder in your repo. Your agent can read them, reviewers see the diff, and you can delete the folder whenever you like.
It also does what copy-paste can't: apiweld.lock.json records exactly which spec your client came from, so Apiweld can tell you when upstream changes something you rely on.
apiweld.config.ts # what you want
apiweld.lock.json # what was built, pinned by hash
src/apis/stripe/ # generated, committed, yours
sdk.gen.ts
types.gen.ts
zod.gen.ts
index.tsFrom “I need to refund a payment” to a reviewed client
Run each step yourself in the terminal, or let your agent call it through MCP. Both use the same commands.
01
Find the endpoint
Search every operation in the catalog by what it does. “Refund a payment” returns Stripe's POST /v1/refunds. The agent sees a short TypeScript signature, not the full spec.
02
Add only what you call
apiweld add writes a typed client for the endpoints you picked into src/apis/. It's plain TypeScript you commit, read, and review. There's no runtime dependency on Apiweld.
03
Know when it changes
apiweld check diffs the upstream spec against your lock. It only reports changes to the endpoints you use, and it sorts each one into breaking, risky, or safe.
04
Fix it with the compiler
Breaking changes get a heal plan: the new client goes into a separate worktree, tsc finds the call sites that break, and your agent fixes them. You review the branch and merge it yourself.
How it compares
Apiweld sits between a vendor SDK and generating the whole spec. It builds on tools that already work: Hey API generates the code and oasdiff classifies the changes.
| Capability | Hand-written fetch | Vendor SDK | Full OpenAPI codegen | Apiweld |
|---|---|---|---|---|
| Typed against the current spec | No | Usually | Yes | Yes |
| Only the endpoints you call | Yes | No | No | Yes |
| Code lives in your repo | Yes | No | Yes | Yes |
| Works when there's no SDK | Yes | No | Yes | Yes |
| Your agent can search for the endpoint | No | No | No | Yes |
| Tells you which call sites a change breaks | No | No | No | Yes |
Tools like Composio give agents API access at runtime. Apiweld works at build time: it produces code that ships with your app and runs without an agent.
Runs on your machine
No accounts, no hosted service, no telemetry. The only network calls are GETs for public specs. Everything works offline from the cache.
Your agent does the thinking
Apiweld never calls an LLM. Search, generate, diff, and type-check are deterministic. Claude Code, Cursor, or any MCP client calls the same commands you do.
Git is the database
A TypeScript config says what you want. A JSON lockfile pins what was built. Every change to a client is a diff you can review.
Documentation
Written for you and for your agent. Every page has a Markdown version, and /llms.txt lists them all.
- OverviewWhat Apiweld is, why it exists, and the terms these docs use.
- QuickstartFrom an empty repo to a typed Stripe refund client.
- MCP toolsLet your coding agent search, add, and heal.
- Drift detectionWhat counts as breaking, and what stays quiet.
- Heal loopFrom a breaking change to a green type-check.
- CLIEvery command, with --json for scripts and CI.
- Config and lockfileTypeScript for what you want, JSON for what was built.
- PrinciplesThe rules behind the design.
- SecurityUntrusted specs, an offline engine, and what the server can write.
- ArchitectureCatalog, engine, slicer, and the Hey API adapter.
