Who publishes this
Voxgig publishes these pages and makes one of the tools compared on them. The sources are linked on every page so the claims can be checked against the vendors' own documentation.
Scope and method#
Nine generators, one page each, all following the same shape. Each page starts with what the tool is, what it does that Voxgig does not, and a side-by-side table. It goes on to one API with an SDK from each, the cases each tool suits, and the limits of the comparison.
The axes are licensing and ownership, language and framework targets, what the tool generates besides an SDK, how customizations survive regeneration, what cross-cutting behavior comes built in, and how it is priced. Those are the differences that tend to decide the choice; the pages state them and leave the weighting to you.
Facts on every page were last checked on . Voxgig publishes these pages and makes one of the tools compared. The six rules below describe how they are sourced and corrected.
How these pages are written#
Six rules every page follows. If a page breaks one, tell us; corrections are below.
Capabilities, not verdicts
Each page describes what a tool does and what it does not do. Where the two tools differ, the difference is stated and you decide which side of it you are on. No tool is scored, and no overall winner is declared.
No asterisks in the table
If a tool has a feature, the table says it has it. No partial ticks and no footnoted almosts. Where a row would need a paragraph to be accurate, it is a paragraph in the page instead of a row in the table.
Dated facts, first-party sources
Every page carries the date its facts were last checked and links the vendor's own pages, including their comparisons of Voxgig. Pricing and tier limits move fastest, so the pages describe the shape of the pricing and link the vendor for the numbers.
Sources are named, including their limits
Claims come from published documentation, public repositories of generated output, and direct use. Each page's caveats say which, and name what has not been tested. The SDK pairs are the one measurement: one API per tool, in TypeScript, against a mock of its definition. Nothing here is a benchmark across APIs.
Corrections are made and dated
A correction changes the page and moves its checked date. Corrections from maintainers and other vendors carry the most weight, because they come from the people with the best information about the product.
The field at a glance#
The coarse version. Every row links to a page, because the detail that usually decides the choice does not fit in a table.
| Tool | What it is | License | Languages | Cost |
|---|---|---|---|---|
| Voxgig | Open-source generator, six output surfaces | MIT | 20 bundled, 3 from the langpack | Free |
| OpenAPI Generator | Open source, community governed | Apache 2.0 | 40+ client, 20+ server | Free |
| Speakeasy | Commercial, generator AGPL-3.0 since September 2026 | AGPL-3.0 generator, output by election | 8, plus Terraform | Free under AGPL, then quoted |
| Fern | Open-source CLI, commercial docs platform | Apache 2.0 plus commercial | 9 | Free tier, then per SDK. Docs paid |
| Stainless | Commercial, winding down | Proprietary | 9, including Terraform | No longer sold |
| Cloudflare Forge | Open-source pipeline, from Cloudflare | Apache 2.0 | 9, all through Fern's generators | Free |
| APIMatic | Commercial platform and portal | Proprietary | 7 | Low entry tier, then paid |
| liblab | Commercial, pipeline focused | Proprietary | 6, plus Terraform | Tiered subscription |
| Kiota | Open source, from Microsoft | MIT | 8, five stable | Free |
| Hey API | Open source, TypeScript first | MIT | TypeScript, Python in development | Free |
Language counts are targets a tool ships, not a quality measure: a target existing says nothing about how well it is maintained or how idiomatic its output is. Voxgig's 23 is the 20 language targets in the released generator plus Dart, Haskell and Lean from its language pack, @voxgig/sdkgen-langpack.
One API per tool, two SDKs each#
Every page sets an SDK made with the tool, as the API's owner publishes it, beside a Voxgig SDK for the same API, and links both. Both were run against a mock of the API's definition on the same four steps, list, load, create and remove, in TypeScript only. Eight of the Voxgig SDKs are built from the same source definition as their counterpart. They are public repositories under github.com/voxgig-sdk that exist to be compared and are never released, and each carries its full scorecard. For two of them, Lob and Novu, the vendor's SDK came from an older version of that definition, and their pages say so.
Across those eight pairs, the Voxgig SDKs expose 1,157 of the 1,161 operations the definitions declare, and the vendors' SDKs 1,106 methods between them, most of the difference coming from Lob's older SDK. Against the mocks, the vendors' SDKs got 27 of 32 steps right and the Voxgig SDKs 31. The one step Voxgig misses is Maxio's customer list, which returns each customer inside Maxio's { customer } wrapper, because Voxgig's toolchain unwraps a page but not each record in it. Each page names the defects the pair found in Voxgig beside the gaps in the other SDK, with the release that fixed each one that is fixed.
| Tool | API | Their SDK | Voxgig SDK | Operations callable | Mock scenario, steps right |
|---|---|---|---|---|---|
| OpenAPI Generator | Lob | @lob/lob-typescript-sdk 1.4.2 | voxgig-sdk/lob-sdk | Theirs: 70 methods Voxgig: 105 of 105 | Theirs: 4 of 4 Voxgig: 4 of 4 |
| Speakeasy | Novu | @novu/api 3.19.1 | voxgig-sdk/novu-sdk | Theirs: 149 methods Voxgig: 148 of 149 | Theirs: 2 of 4 Voxgig: 4 of 4 |
| Fern | Vapi | @vapi-ai/server-sdk 2.0.1 | voxgig-sdk/vapi-sdk | Theirs: 139 methods Voxgig: 139 of 139 | Theirs: 4 of 4 Voxgig: 4 of 4 |
| Stainless | Mux | @mux/mux-node 15.3.0 | voxgig-sdk/mux-sdk | Theirs: 154 methods Voxgig: 153 of 153 | Theirs: 4 of 4 Voxgig: 4 of 4 |
| Cloudflare Forge | Cloudflare | The SDK inside cf 1.0.0-beta.5 | voxgig-sdk/cloudflare-dns-sdk | Theirs: 68 of 76 Voxgig: 75 of 76 | Theirs: 4 of 4 Voxgig: 1 of 4 |
| APIMatic | Maxio Advanced Billing | @maxio-com/advanced-billing-sdk 10.0.0 | voxgig-sdk/maxio-advanced-billing-sdk | Theirs: 249 of 268 Voxgig: 266 of 268 | Theirs: 4 of 4 Voxgig: 3 of 4 |
| liblab | SaladCloud | @saladtechnologies-oss/salad-cloud-sdk 0.9.0-alpha.17 | voxgig-sdk/saladcloud-sdk | Theirs: 36 methods Voxgig: 36 of 36 | Theirs: 1 of 4 Voxgig: 4 of 4 |
| Kiota | Apicurio Registry | @apicurio/apicurio-registry-sdk 3.3.3 | voxgig-sdk/apicurio-registry-sdk | Theirs: 132 methods Voxgig: 132 of 132 | Theirs: 4 of 4 Voxgig: 4 of 4 |
| Hey API | Neon | @neon/sdk 6.1.2 | voxgig-sdk/neon-sdk | Theirs: 177 methods Voxgig: 178 of 179 | Theirs: 4 of 4 Voxgig: 4 of 4 |
Cloudflare is the exception. Forge's first SDK covers the whole API and is private to the cf CLI. Cloudflare's definition is too large for one Voxgig SDK, so the Voxgig build of it is 34 SDKs, one per product area; the Cloudflare page lists all 34 and compares the DNS one. Its figures cover the DNS operations only, and are not in the totals above.
The comparisons#
Nine tools, one page each. Each page starts with what the tool is, what it does that Voxgig does not, and a side-by-side table. It goes on to one API with an SDK from each, the cases each tool suits, and the limits of the comparison.
OpenAPI Generator
The community generator most APIs have shipped an SDK from at least once. Apache 2.0, community governed, and broader than everything else here put together: 40+ client languages, 20+ server frameworks, plus docs, Postman collections and Protobuf. Breadth is the whole point, and the cost of it.
OpenAPI Generator and Voxgig, comparedLob, one SDK from eachSpeakeasy
Commercial SDK generation whose generator became AGPL-3.0 open source in September 2026. A generator you run from a CLI in your own CI, with Terraform providers, MCP servers and CLIs among its outputs and OpenAPI Overlays as its customization format. Since 17 September 2026 the generator is open source under AGPL-3.0, released with Google, and the license of what it generates is elected at generation time.
Speakeasy and Voxgig, comparedNovu, one SDK from eachFern
SDKs and a documentation site from one definition. Part of Postman since January 2026. An Apache 2.0 CLI and generator set with a commercial hosted documentation platform on top. Takes OpenAPI, AsyncAPI, gRPC and OpenRPC, or its own definition format, and is the best integrated docs and SDK story in this comparison. Since 2026 it also generates a CLI, in early access, and its generators run inside Cloudflare's Forge.
Fern and Voxgig, comparedVapi, one SDK from eachStainless
The generator behind many of the best-known AI SDKs. Its hosted product is winding down. Stainless generated the official client libraries for OpenAI, Anthropic, Cloudflare and several hundred other providers, and set the quality bar this whole field aims at. Anthropic acquired it in May 2026 and is winding down the hosted generator.
Stainless and Voxgig, comparedMux, one SDK from eachCloudflare Forge
Cloudflare's open-source generation pipeline, published on 28 September 2026. Apache 2.0, from the operator of an API with more than 3,500 operations. A pluggable pipeline that resolves OpenAPI, applies JSONPath overlays and chains transformers: Fern's generators for nine languages, TypeScript included, and, inside Cloudflare, the SDK and commands behind the cf CLI. Most of what the announcement describes is still ahead of the repository.
Cloudflare Forge and Voxgig, comparedCloudflare, one SDK from eachAPIMatic
The longest-running commercial generator here, and the only one that converts between description formats. SDKs in seven languages, a developer portal, spec validation, and API Transformer, which converts API descriptions between more than fifteen formats. The lowest entry price of the commercial tools on this site.
APIMatic and Voxgig, comparedMaxio Advanced Billing, one SDK from eachliblab
SDK generation shaped as a release pipeline. Part of Postman since November 2025. Commercial SDK generation whose center of gravity is publishing rather than generating: version, changelog and push packages to npm, PyPI, Maven, and NuGet on every spec change. Generates and hosts an MCP server from the same specification. Acquired by Postman in November 2025.
liblab and Voxgig, comparedSaladCloud, one SDK from eachKiota
Microsoft's client generator, built so you do not need a separate SDK per API. MIT, from Microsoft, and pointed at the other side of the API. Kiota is for the team calling somebody else's API, with one shared HTTP stack and fluent request builders across every API you consume.
Kiota and Voxgig, comparedApicurio Registry, one SDK from eachHey API
The TypeScript ecosystem's generator, with a Python generator in early development. MIT, millions of weekly npm downloads, and a plugin architecture that generates exactly what you ask for: types, a client, Zod schemas, TanStack Query hooks. TypeScript today, with a Python generator in initial development. On TypeScript specifically it is the more specialized tool.
Hey API and Voxgig, comparedNeon, one SDK from eachWhat the decision usually turns on#
Only one of these five questions is about generated code.
- Who owns the generator. A vendor tool means a subscription, a roadmap and someone to escalate to. An open-source generator in your repository means maintenance you take on yourself. Both are workable; the failure mode is not noticing the choice was being made.
- How many languages will actually ship. Two makes per-language subscription pricing cheap; seven makes it the largest line on the invoice. The relevant count is what customers will ask for in two years, not what exists today.
- What happens on the fortieth change to your API description. This is where hand-written and AI-written SDKs stop being comparable to generated ones. It is also where a generator that cannot preserve your customizations starts costing more than it saves, because every regeneration becomes a merge you supervise.
- Whether agents need to call your API. An MCP server generated from the same description as the SDK cannot drift from it; a hand-written one drifts on the next release. Of the tools compared here, Speakeasy, liblab and Voxgig generate one, and APIMatic has one in alpha. Cloudflare names one among Forge's intended outputs, and Fern hosts one for the documentation rather than the API. Stainless generated one too, but its hosted generator is winding down.
- What happens when the vendor is bought. In the ten months to May 2026, three of the tools on this page changed hands. liblab went to Postman in November 2025, Fern to Postman in January 2026, and Stainless to Anthropic in May 2026. Stainless's hosted generator closed to new projects the day the acquisition was announced. Two of the largest customers of the tool that closed answered in the open. Google co-released Speakeasy's generator under AGPL-3.0 in September 2026, and Cloudflare published Forge, its own Apache 2.0 pipeline, the same month.
The risk of choosing Voxgig#
Question five applies to Voxgig as well.
Voxgig Ltd is a small independent company trading since 2018, with no external owner and no support contract on offer. If development stopped, the generator is MIT on npm and GitHub and the generated code is already in the consuming repository, so builds continue and regeneration continues. What stops is development: the result is a generator nobody is maintaining, which is a different position from a hosted generator being switched off, and not the same as nothing changing.
A smaller project also means a smaller community: fewer answered questions in public, and fewer engineers who have hit a given edge case before. A new hire is less likely to have used it. A commercial vendor offers a support contract and an SLA against that.
The SDK pairs measure the output as well. Against a mock of each definition, Voxgig's SDK got fewer steps right than the other tool's in two of the nine pairs, the same number in five, and more in two. Each page names the defects in Voxgig's toolchain behind its result.
What Voxgig does not do. No Terraform provider target, which Speakeasy and liblab have and Cloudflare says Forge will; one is designed for Voxgig's infrapack and has not been built. No hosted documentation platform, which Fern has; docgen generates a static reference site you host. No package publishing to registries, which liblab and APIMatic do. No hosted MCP endpoint, which liblab runs for you. No server stubs, which OpenAPI Generator generates. No per-change preview builds in CI, which Forge is built around. 23 language targets against OpenAPI Generator's list of roughly four times that. And a smaller company than every commercial tool compared here.
The wider field#
Tools without a page of their own, with a line each: those that solve an adjacent problem, and those with too little direct use behind them to compare in detail.
- Swagger Codegen The ancestor of most of this field, still maintained by SmartBear. OpenAPI Generator forked from it in 2018 and took most of the community. Check which one you are actually running, because plenty of build files still say this one.
- AutoRest Microsoft's earlier generator, built around Azure's needs and still used across the Azure SDKs. Superseded by Kiota for general client generation, but a lot of production code depends on it.
- NSwag The .NET ecosystem's long-running toolchain: C# and TypeScript clients, plus server-side specification generation from ASP.NET controllers. Generating the description from the code rather than the other way round is a legitimate workflow that none of the tools above serve.
- openapi-typescript and openapi-fetch Types straight from the specification, plus a tiny typed fetch wrapper. Not really a generator: no client class, no features, almost no output. For a lot of TypeScript projects that is exactly the right amount of tool.
- orval and Kubb Two more TypeScript generators aimed at frontend data layers, with React Query, SWR and MSW mock output. Same territory as Hey API, different opinions about it.
-
openapi-python-clientA single-language generator for Python that produces markedly more idiomatic output than a general-purpose tool aiming at forty languages. The same argument Hey API makes for TypeScript, made for Python. - Progenitor Oxide's Rust generator, emitting a client as a procedural macro or a build step. Narrow, sharp, and the reference for what generated Rust should look like.
- Smithy AWS's protocol-agnostic interface definition language, designed for code generation rather than adapted to it, and the model behind the AWS SDKs. The closest thing in the industry to Voxgig's semantic model argument, arrived at independently and at a much larger scale. It converts to OpenAPI, so it can feed the tools above.
- TypeSpec Microsoft's language for describing APIs concisely and emitting OpenAPI, Protobuf and JSON Schema from one definition. Solves the same authoring problem as Fern Definition, in the open, with an emitter model. Increasingly the front end other people's generators are pointed at.
- Sideko and Konfig Smaller commercial entrants in the same shape as Speakeasy and Fern: SDKs plus documentation, per-seat or per-language. For any vendor of this size, including Voxgig, check it is still trading before building a release pipeline on it.
- Scalar The API documentation company's hosted generator, closed source and priced per SDK target by endpoint count. TypeScript, Python, Go and a CLI are generally available and nine more languages are experimental. It reads a stainless.yml as input and does a three-way merge on every rebuild, which is aimed at the Stainless customers choosing a successor.
- stainful An MIT generator from a single maintainer that reads an existing stainless.yml unchanged and produces a Python SDK from it, locally, with no service behind it. Python only and at version 0.4 on the checked date. The cheapest continuation path for a Stainless Python SDK, with one person's availability as its main risk.
- Buf and Connect If your API is gRPC or Protobuf, generation is already the normal way of life and the toolchain is mature. The whole argument on this site, that clients should be generated from a machine-readable description, was settled years ago in that world.
A tool missing from this list? Send it.
Corrections#
These pages describe other vendors' products, and those products change.
Prices change, features ship and roadmaps move, so a page accurate on its checked date goes stale on its own. Corrections are the mechanism for that.
Mail the address below, or open an issue if you prefer a public record.
What is useful in a correction: the page, the sentence, what is wrong, and where the correct answer is published. A link to first-party documentation settles it fastest. Objections to the framing rather than the facts are equally welcome.
What happens next: we check the claim against the published source, update the page and its checked date, and reply to you saying what changed. If we do not accept a correction, we reply saying why.
Maintainers and vendor teams especially. Corrections from the people who build the product carry the most weight, because they come from the best available information about it.
FAQ#
Who publishes these pages?
Voxgig, which makes one of the tools compared. Every page carries the date its facts were checked and links the vendor's own documentation, including their comparisons of Voxgig, so the claims can be checked at source.
How do you decide which tools get a page?
Any tool a team could reasonably shortlist alongside Voxgig, weighted by how often it comes up. License, company size and commercial model do not affect that. Tools solving an adjacent problem, and tools we have not used enough to describe in detail, get a line in the wider field instead.
A page is wrong about my tool. What happens if I tell you?
Send it to info@voxgig.com or open an issue on the generator repository. The most useful correction names the page, the sentence, what is wrong and where the correct answer is published. A correction changes the page and moves its checked date.
Do you benchmark the generated code?
Not across APIs. Each page sets an SDK made with the tool beside a Voxgig SDK for the same API, and both were run against a mock of that API's definition, in TypeScript. Over the eight pairs, the Voxgig SDKs exposed more operations, most of the difference coming from Lob's older SDK, and got more mock steps right, 31 of 32 against the other SDKs' 27, and each page says why. That is evidence about those SDKs, not a ranking of the generators. The rest of each page comes from published documentation, public repositories of generated output, and direct use, and says which.
Why does the Stainless page exist if the product is winding down?
Because it generated a large number of published SDKs, and their maintainers need an account of what changed and what the options are. It normalized several conventions the field works to, including standardized streaming and auto-pagination.
What is the fastest way to decide without reading all of this?
Three questions. How many languages will actually ship, because per-SDK pricing is cheap at two and expensive at seven. Whether agents need to call the API, because an MCP server generated from the same description as the SDK cannot drift from it. And what happens if the vendor is bought, because three of the tools here changed hands in the ten months to May 2026. Two of the largest customers of the tool that closed answered by open-sourcing generators in September.
Why is Cloudflare Forge here when it was published on 28 September 2026?
Because it comes from the operator of one of the largest public APIs, whose SDKs were generated by Stainless until that generator began winding down. A team choosing a generator will be asked about it. It is the youngest tool compared here, so its page will go stale faster than the other eight. Where the first-party sources that page links disagree with it, they are the authority.
Read the generated code#
The generator is MIT, and the catalog holds 600+ generated SDKs readable without installing anything.