Open-source generator for API-first SaaS. Your OpenAPI spec becomes six surfaces, and they all regenerate together every time you change it.
Voxgig models your API as semantic, type-safe entities, and the operations on those entities. The model is the ground truth for generating dependable and friendly developer experiences, and giving your agents accurate and deterministic context.
Uniform client libraries focused on developer intent, in 23 languages: TypeScript, JavaScript, Go, Python, PHP and Ruby, through to Rust, Kotlin, Swift, Elixir and OCaml. You call entities and operations, not URLs. Retries, caching, idempotency and tracing come built in.
A command-line tool over your API, terse and entity-shaped: $ myapi load myentity, not a URL path. Power users, scripts, on-call, CI.
A Model Context Protocol server, so Claude, ChatGPT, Cursor, and Cline can 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 instead of guessing at it.
An interactive shell over the same entities. A new developer can npx it in 30 seconds, authenticate, and poke around.
A type-safe model of your API as entities, their attributes, and the operations on them. The ground truth behind every other surface, so nothing drifts, and a foundation you can build your own tooling on.
Wrapping endpoints is the easy half. Voxgig also generates the nineteen features that usually get written by hand, badly, once per language: retry, timeout, ratelimit, cache, idempotency, paging, streaming, telemetry, metrics, audit, cost, debug, clienttrack, rbac, proxy, secrets, log, test and netsim. All opt-in, all configured from the constructor, all implemented in every language we generate.
retry with exponential backoff, jitter and Retry-After. timeout that actually 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 repo, your decisions are declared in the model, and your own features and targets are peers of ours. Regeneration stays safe the whole time, and a doctor command proves it.
Scaffolding copies the generator's two layers into your repo: 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 always safe to run.
A custom feature is a model file plus per-language source, on the same pipeline hooks the shipped nineteen use, tested by the same language-neutral corpus. The demo's elementcard renders ASCII periodic-table tiles in five languages.
A target is an output product generated from your model, like the SDK in each language, the CLI, or the MCP server. Nothing hardcodes the shipped list, so yours is a peer of ours. 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.
First customer wants Go. Next wants Python. Now you own N SDKs, and every API change is N updates, N test suites, N customer migrations. The cost grows with every language you add.
AI agents are already calling your API, and they want an MCP server, not 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 repo 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, agents that call APIs (which is what MCP is for, and we ship MCP output ourselves). The specific tradeoff 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.
Here is our view. SDKs are infrastructure. They sit between your API and every customer integration. Your customers compile them into production binaries and depend on them across years of releases. For that kind of artefact, deterministic generation pays off: same spec, same SDK, every time, every machine, every CI run. Other teams will weigh it differently. This page is the case for how we weigh it.
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. Voxgig generates every other surface from that one model, which is why they stay in sync and why the same spec always 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, not URL paths and JSON schemas. That is why the CLI is $ myapi load myentity rather than a verbose path, and the same semantic layer carries through the SDK calls, the MCP Server, the Agent Skills, and the REPL.
Voxgig's call: a type-safe model of your API, then hybrid template plus programmatic generation. Open source. You can read it. Deterministic.
This table compares approaches. For named tools, there is a page each: SDK generator comparisons covers OpenAPI Generator, Speakeasy, Fern, Stainless, 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 in five minutes from the spec you already have. Try it tonight. |
| 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. All that 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. Same spec, same SDK, every time. The engine is open source and 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, no MCP. No commercial team behind it when it breaks. | Output that reads like a human wrote it, and is still deterministic. Six surfaces, and nineteen features in every language. A team behind it. |
| Paid SaaS SDK | SDK only. Closed source. Priced per seat. | All six surfaces. Open source. MIT, in your repo. |
| Hand-rolled MCP server | Solves MCP on its own, then drifts from your SDK on the next spec change. | SDK and MCP from the same spec, in sync, every time. |
Do not take our word for any of this. The catalog has 600+ generated SDKs you can read before you install a thing.
github-rest-sdk · npm-registry-sdk · claude-sdk · microlink-sdk
nasa-open-apis-sdk · openfda-sdk · musicbrainz-sdk · rest-countries-sdk
voxgig-solardemo-sdk, Voxgig's own demo API, the Go reference. voxgig-elementdemo-sdk, the customization reference: a custom Bash target and a custom feature.
Two minutes from 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 · npm: @voxgig/sdkgen
Handing the build to an AI agent? The agent guide is the entry point written for it: the runbook, the rules, and why deterministic generation suits agent work.
No OpenAPI spec yet? You do not need one to start. Our 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.
Developer ExperienceThe open source is usually enough. When it is not, the same people who built the generator do the work as an API Experience engagement.
Take the generated SDKs to production grade: reads well, tested, documented, wired into a release pipeline.
Developer ExperienceAn MCP server agents can actually use: proper tool schemas, errors an agent can recover from, generated from the same spec.
Agent ExperienceA DevRel program built around the developer-facing surface, run by people who have done it before.
Developer RelationsYou can, and many teams do. Make that tradeoff 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. That is useful for exploration and harder to live with for libraries your customers compile against for years. Voxgig's generator is hybrid template plus programmatic: same spec, same SDK, every time. We use AI elsewhere, including for MCP output. We just made the call that for SDK generation specifically, 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 repo. Nothing breaks. We have been a company for seven years. API Experience is where we make money, the open source is for the community.
Twenty-three language targets are available. Twenty-two ship with the generator: TypeScript, JavaScript, Go, Python, PHP, Ruby, Lua, C#, Java, Kotlin, Scala, Swift, Dart, Rust, C, C++, Zig, Perl, Clojure, Elixir, OCaml and Lean. Haskell comes as a separate package. You add the ones you want and generate only those. Every target gets the same operation pipeline, the same nineteen features, generated docs and an offline test suite, which is the whole point of generating rather than hand-writing: the retry policy is the same policy in Go as it is in TypeScript. The generator README carries the current list, and it is the one to trust if this page has fallen behind it.
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. Nineteen 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, 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, and 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, with 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 APIMatic, liblab, Kiota and Hey API. Each page covers what the other tool does that Voxgig does not, a side-by-side table, 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 us and the page says which. All the comparisons.
Same company, separate business line. The Developer Relations work and Fireside podcast have run since 2018. The SDK product launched in 2026. The thread between them is Developer Experience, and now Agent Experience.
@voxgig/sdkgen