SDK
Uniform client libraries focused on developer intent, in TypeScript, JavaScript, Go, Python, PHP, and Lua. You call entities and operations, not URLs. Retries, caching, idempotency and tracing come built in. 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 dependable and friendly developer experiences, and giving your agents accurate and deterministic context.
CLI
A 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 calls your 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.
And the parts you would otherwise hand-write#
Wrapping endpoints is the easy half. Voxgig also generates the eighteen 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, log, test and netsim. All opt-in, all configured from the constructor, all implemented in every language we generate.
Resilience
retry with exponential backoff, jitter and Retry-After. timeout that actually aborts the transport. ratelimit as a token bucket. cache for safe reads.
Correctness
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.
Operations
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.
And when the stock output is not enough#
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.
Own the templates
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.
Add your own feature
A custom feature is a model file plus per-language source, on the same pipeline hooks the shipped eighteen use, tested by the same language-neutral corpus. The demo's elementcard renders ASCII periodic-table tiles in five languages.
Add your own target
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.
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. The cost grows with every language you add.
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 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.
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. 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 eighteen 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. |
Read 600+ examples before you install#
Do not take our word for any of this. The catalog has 600+ 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. voxgig-elementdemo-sdk, the customization reference: a custom Bash target and a custom feature.
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
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 ExperienceWhen you outgrow self-serve#
The open source is usually enough. 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: proper 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. 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.
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.
600 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. What the number buys you is choice: find one shaped like your API and read the code before you install.
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 API's own operations instead of guessing at URLs.
Do the generated SDKs handle retries, caching and pagination, or is that my job?
They handle it, if you ask them to. Eighteen 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, 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.
What happens when the generated output is not quite right for us?
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.
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
600+ examples
read the code at github.com/voxgig-sdk
Backed by Voxgig
Dublin & Brentford, since 2018