Open source generator for API-first SaaS. Your OpenAPI spec becomes six surfaces, and all six regenerate together every time you change it.
Voxgig reads your OpenAPI spec into a type-safe model of your API: the entities, their attributes, and the operations on them. Every surface below is generated from that one model, so a change to the spec reaches all six on the next run.
Client libraries in 23 languages: TypeScript, JavaScript, Go, Python, PHP, and Ruby, through to Rust, Kotlin, Swift, Elixir, and OCaml. You call entities and operations rather than URLs, and retry, caching, idempotency, and tracing are generated features you switch on.
A command-line tool over your API, entity-shaped: myapi load myentity rather than a URL path. For scripts, CI, and on-call work.
A Model Context Protocol server, so Claude, ChatGPT, Cursor, and Cline call your API as a native tool.
Generated markdown that teaches a coding agent your entities and operations, so chat-driven work calls your API rather than guessing at it.
An interactive shell over the same entities. A new developer runs it with npx, authenticates, and tries a call before writing any code.
A type-safe model of your API: its entities, their attributes, and the operations on them. The other five surfaces are generated from it, so they cannot drift apart, and your own tooling can be built on it.
Wrapping endpoints is the mechanical half. Voxgig also generates the twenty features that usually get written by hand, once per language: retry, timeout, ratelimit, cache, idempotency, paging, streaming, telemetry, metrics, audit, cost, debug, clienttrack, rbac, proxy, secrets, validate, log, test, and netsim. Every one is opt-in, configured from the constructor, and implemented in every language the generator targets.
retry with exponential backoff, jitter, and Retry-After. timeout that aborts the transport. ratelimit as a token bucket. cache for safe reads.
idempotency keys generated once per operation and stable across every retry of it, so a retried write does not become two. paging that reads whichever convention your API picked and knows when to stop.
telemetry spans with W3C trace context, metrics, an audit record per call, a redacted debug buffer, rbac, proxy support, and a mock transport you can fail on purpose.
The reason teams fork generators is that customizing feels impossible. Here, customization is the architecture: templates and components sit in your repository, your decisions are declared in the model, and your own features and targets are peers of the shipped ones. Regeneration stays safe the whole time, and a doctor command proves it.
Scaffolding copies the generator's two layers into your repository: the templates that are the same for every API, and the components that write the API-shaped parts. Your decisions are declared in the model, so regeneration is safe to run.
A custom feature is a model file plus per-language source, on the same pipeline hooks the shipped twenty use, tested by the same language-neutral corpus. The demo's elementcard feature renders ASCII periodic-table tiles in five languages.
A target is an output product generated from your model: the SDK in each language, the CLI, or the MCP server. Nothing hardcodes the shipped list, so a target you add is a peer of the ones Voxgig ships. The demo adds a Bash SDK, curl and jq, generated from the same model as the TypeScript one.
Two pressures land on every API-first SaaS inside a year of the first enterprise customer. One engineering principle sits underneath both.
Your first customer wants Go. The next wants Python. Now you own N SDKs, and every API change is N updates, N test suites, and N customer migrations. The cost grows with every language you add.
AI agents are already calling your API, and they want an MCP server rather than raw HTTP. Hand-roll one and it drifts from your SDK on the next release.
It does not matter who writes the code. The SDK sits in your repository and your customers compile against it. The tool changes who writes. It does not change who owns.
AI coding assistants are good at plenty of things: exploration, prototyping, internal scripts, and agents that call APIs, which is what MCP is for, and Voxgig ships MCP output itself. The specific trade-off for SDK generation is determinism. AI generation produces different code for the same input on every run. In some places that is fine. In others it is a liability.
SDKs are infrastructure. They sit between your API and every customer integration, and your customers compile them into production binaries and depend on them across years of releases. For that kind of artifact, deterministic generation pays off: the same spec produces the same SDK on every machine and every CI run. Other teams weigh it differently. This is the Voxgig case for weighing it this way.
Determinism comes from a model. Voxgig extracts a type-safe model of your API first: the entities, their attributes, and the operations the API offers on them. Every other surface is generated from that one model, which is why they stay in sync and why the same spec yields the same code. The model also raises the level you work at. The people building the SDK and the people using it both think in entities and operations rather than in URL paths and JSON schemas. That is why the CLI is myapi load myentity rather than a verbose path. The same semantic layer carries through the SDK calls, the MCP Server, the Agent Skills, and the REPL.
The Voxgig call: a type-safe model of your API, then hybrid template plus programmatic generation. Open source, so you can read it, and deterministic.
This table compares approaches. For named tools, there is a page each: SDK generator comparisons covers OpenAPI Generator, Speakeasy, Fern, Stainless, Cloudflare Forge, APIMatic, liblab, Kiota, and Hey API. Published by Voxgig, which makes one of the tools compared. Each page carries dated facts, first-party sources, and the limits of the comparison.
| Approach | What it costs you | What Voxgig does instead |
|---|---|---|
| Ship no SDK | You lose the enterprise deal, or you ship raw HTTP and your customers complain in Slack for a year. | Generation from the spec you already have, in one command. |
| Hand-write SDKs per language | Every API change is N writes. The SDKs drift from your spec. You hire a specialist per language. If you build it, you own it. | One spec, every language you ship, in sync. The maintenance becomes a single regenerate. |
| AI-assisted generation | The ownership cost is identical to hand-writing. The output is non-deterministic, different code on every run, which is fine for exploration and a harder thing to live with for libraries customers compile against for years. | Deterministic template plus programmatic generation: the same spec produces the same SDK on every run. The engine is open source, so you can read it. |
| Other open source generators | Wooden output. Endpoint wrappers and nothing else, so retries, caching, idempotency, and tracing still fall to you, once per language. No CLI, no REPL, and no MCP. Nobody behind it when it breaks. | Output that reads as if a person wrote it, and is still deterministic. Six surfaces, and twenty features in every language. A team behind it. |
| Paid SaaS SDK | SDK only. Closed source. Priced per seat. | All six surfaces, open source under MIT, in your repository. |
| Hand-rolled MCP server | Solves MCP on its own, then drifts from your SDK on the next spec change. | SDK and MCP server from the same spec, so they cannot disagree. |
The catalog holds more than 600 generated SDKs you can read before you install anything.
github-rest-sdk · npm-registry-sdk · claude-sdk · microlink-sdk
nasa-open-apis-sdk · openfda-sdk · musicbrainz-sdk · rest-countries-sdk
voxgig-solardemo-sdk, the Voxgig demo API and the Go reference. voxgig-elementdemo-sdk, the customization reference: a custom Bash target and a custom feature.
One command takes a clean checkout to generated code. The CLI walks you through your spec, your target languages, and which of the six surfaces to ship: SDK, CLI, MCP Server, Agent Skills, REPL, and Semantic Model.
Source: github.com/voxgig/sdkgen. Package: @voxgig/sdkgen on npm.
If an AI agent is doing the build, the agent guide is the entry point written for it: the runbook, the rules, and why deterministic generation suits agent work.
Without an OpenAPI spec you can still start. The Developer Experience service designs an accurate spec with you, from your existing API or from scratch, so the generator has a clean source of truth.
See the Developer Experience serviceThe open source is usually enough. When it is not, the people who built the generator do the work as an API Experience engagement.
Take the generated SDKs to production grade: readable, tested, documented, and wired into a release pipeline.
See the Developer Experience serviceAn MCP server agents can use: tool schemas that fit, errors an agent can recover from, and all of it generated from the same spec.
See the Agent Experience serviceA developer relations program built around the developer-facing surface, run by people who have done it before.
See the Developer Relations serviceYou can, and many teams do. Make that trade-off on purpose rather than by default. The ownership cost is the same whatever wrote the code, so the thing to weigh is determinism. AI generation gives you different code for the same input on every run, which is useful for exploration and harder to live with for libraries your customers compile against for years. The Voxgig generator is hybrid template plus programmatic, so the same spec produces the same SDK on every run. Voxgig uses AI elsewhere, including for MCP output, and made the call that for SDK generation determinism wins.
Yes. The generator and the templates are MIT. The generated SDKs in your repo are yours, under whatever license you choose to ship them under.
The generator is on npm and GitHub. The generated code is in your repository. Nothing breaks. Voxgig Ltd has traded since 2018. API Experience is where the money is made, and the open source is for the community.
Twenty-three language targets are available. Twenty ship with the generator: TypeScript, JavaScript, Go, Python, PHP, Ruby, Lua, C#, Java, Kotlin, Scala, Swift, Rust, C, C++, Zig, Perl, Clojure, Elixir, and OCaml. Dart, Haskell, and Lean come together in a language pack, @voxgig/sdkgen-langpack. You add the ones you want and generate only those. Every target gets the same operation pipeline, the same twenty features, generated docs, and an offline test suite. That is the reason to generate rather than hand-write: the retry policy is the same policy in Go as it is in TypeScript. The released packages are the authority on what ships: @voxgig/sdkgen and @voxgig/sdkgen-langpack.
The catalog runs wide: open-data APIs (NASA, openFDA, MusicBrainz), developer tools (GitHub, npm, Claude), and a long tail. What the number buys you is choice: find one shaped like your API and read the code before you install.
One of the six output surfaces. The generator emits markdown that describes your API at the entity and operation level, in the format coding agents read as a skill. Point Claude or Cursor at it and chat-driven work uses your API's own operations instead of guessing at URLs.
They handle it, if you ask them to. Twenty features ship with the generator: retry with backoff, timeouts, rate limiting, caching, idempotency keys, pagination, streaming, tracing, metrics, audit records, cost tracking with a spend budget, a debug buffer, RBAC, proxy support, credential resolution with refresh-token exchange, payload validation against the model's own field types, per-client tracking, logging, and an offline mock transport with network simulation. Each one is off until you switch it on in the constructor, and each is implemented for every language target, TypeScript included. Full list and how they compose.
You customize it without forking it. Project decisions are declared in the model and survive every regeneration. The templates and components are copied into your repo. The supported extension points let you add your own components, your own features, and even entire language targets, packaged so an upgrade cannot revert them. A doctor command reports any drift from what a resync would write. How customization works walks through a worked example that generates a Bash SDK.
Yes. The MCP target runs from the same input as the SDK and CLI targets. If your spec is good enough to ship an SDK from, it is good enough to ship an MCP server from.
There is a page for each of them, and for Cloudflare Forge, APIMatic, liblab, Kiota, and Hey API. Each page covers what the other tool does that Voxgig does not, a side-by-side table, and an SDK made with the tool beside a Voxgig SDK for the same API. It also covers the cases each suits and the limits of the comparison, with dated facts and first-party sources. Short version: if you need a Terraform provider, a hosted documentation platform, package publishing, or a server stub, one of them beats Voxgig, and the page says which. All the comparisons.
Same company, separate business line. The Developer Relations work and the Fireside podcast have run since 2018. The SDK product launched in 2026. The thread between them is Developer Experience, and alongside it Agent Experience.
@voxgig/sdkgenSince 2018, Richard Rodger has talked with developer advocates, event organizers, and the people who build developer-facing companies about the specifics of the work.