SDK
Uniform client libraries focused on developer intent, in TypeScript, JavaScript, Go, Python, PHP, and Lua. You call entities and operations, not URLs. Java and C# on request.
Voxgig SDK Generator
Open-source generator for API-first SaaS. Your OpenAPI spec becomes six surfaces, and they all regenerate together every time you change it.
What you get from one spec
Voxgig models your API as semantic, type-safe entities, and the operations on those entities. The model is the ground truth for generating robust and friendly developer experiences, and giving your agents accurate and deterministic context.
CLI
A real command-line tool over your API, terse and entity-shaped: $ myapi load myentity, not a URL path. Power users, scripts, on-call, CI.
MCP Server
A Model Context Protocol server, so Claude, ChatGPT, Cursor, and Cline can call your API as a native tool.
Agent Skills
Generated markdown that teaches a coding agent your entities and operations, so chat-driven work uses your real API instead of guessing at it.
REPL
An interactive shell over the same entities. A new developer can npx it in 30 seconds, authenticate, and poke around.
Semantic Model
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.
Why this exists
Two pressures land on every API-first SaaS inside a year of the first enterprise customer. One engineering principle sits underneath both.
The SDK maintenance tax
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. It compounds.
The agent-experience shift
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.
If you build it, you own it
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.
The choice underneath: deterministic vs. AI-assisted generation
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 is worth a lot: 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 is not magic, it 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.
How it compares, costs and all
| 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, six languages, in sync. The compounding maintenance becomes a single regenerate. |
| AI-assisted generation | A real tradeoff. 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. 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. 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. |
Read 500+ examples before you install
Do not take our word for any of this. The catalog has 500+ generated SDKs you can read before you install a thing.
Developer platforms
github-rest-sdk · npm-registry-sdk · claude-sdk · microlink-sdk
Open data
nasa-open-apis-sdk · openfda-sdk · musicbrainz-sdk · rest-countries-sdk
Reference for polyglot output
voxgig-solardemo-sdk, Voxgig's own demo API, the Go reference.
Your own SDK
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
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 ExperienceWhen you outgrow self-serve
The open source is enough for most teams. When it is not, the same people who built the generator do the work as an API Experience engagement.
Developer Experience
Take the generated SDKs to production grade: reads well, tested, documented, wired into a release pipeline.
Developer ExperienceAgent Experience
An MCP server agents can actually use: real tool schemas, errors an agent can recover from, generated from the same spec.
Agent ExperienceDeveloper Relations
A DevRel program built around the developer-facing surface, run by people who have done it before.
Developer RelationsFAQ
Why not just have an AI assistant generate the SDKs?
You can, and many teams do. It is a real tradeoff, and worth making 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 is worth more.
Is this really MIT-licensed?
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.
What if Voxgig disappears?
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.
Why aren't Java and C# in the default targets?
We generate them on request rather than by default. The open source puts its polish into the six languages above. Java and C# come as part of an API Experience engagement, or behind a --target=java flag.
500 SDKs sounds like a lot of toy APIs.
The catalog runs wide: open-data APIs (NASA, openFDA, MusicBrainz), developer tools (GitHub, npm, Claude), and a long tail. The point is not "look how many." The point is "find one shaped like your API and read the code."
What are "Agent Skills"?
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 real operations instead of guessing at URLs.
Does it generate MCP for any OpenAPI spec?
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.
Is this part of the existing Voxgig DevRel business?
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.
Open source
MIT, on npm as
@voxgig/sdkgenDeterministic
Hybrid template plus programmatic generation
500+ examples
read the code at github.com/voxgig-sdk
Backed by Voxgig
Dublin & Brentford, since 2018