SDK generator comparisons

Kiota and Voxgig, compared

A Microsoft client generator with a different scope from the rest of this field, shortlisted alongside them often enough to be worth a page.

Published by Voxgig, which makes one of the two tools compared here. Facts checked against the first-party sources linked below. Corrections go to info@voxgig.com. The scope and method for every page in this section are published.

What Kiota is#

Kiota is an MIT-licensed command-line generator from Microsoft. It produces strongly typed, fluent API clients for eight targets, C#, Dart, Go, Java, PHP, Python, Ruby and TypeScript, at varying levels of stability per language. The TypeScript target serves JavaScript too.

It was built for Microsoft Graph, an API with thousands of operations, and almost every design decision follows from that. The generated code is deliberately thin. HTTP, serialization, authentication and middleware live in per-language kiota-abstractions packages that you install as dependencies, so the generated client is little more than a typed description of the request surface.

The stated goal, in Microsoft's own words, is to eliminate the need to take a dependency on a different API SDK for every API you call.

That is a different job from the one every other tool on this page does. The rest are bought by the team that owns an API and wants to hand a library to its customers. Kiota is run by the team that has to call twenty other people's APIs and does not want twenty SDKs in its dependency tree.

What Kiota does that Voxgig does not#

Capabilities Kiota has that Voxgig does not, in enough detail to evaluate them.

Shared abstractions instead of a self-contained SDK

One HTTP stack, one serialization layer, one authentication model, one middleware chain, across every API you generate a client for. If you consume fifteen APIs, you configure retry and proxying and telemetry once rather than fifteen times in fifteen vendors' idioms. This is the exact opposite of what Voxgig does, and for the consumer it is clearly the better shape. Voxgig vendors everything into your repository so the generated SDK has no runtime dependency at all, which is what an API provider wants to hand a customer and precisely not what a consumer of fifteen APIs wants to install fifteen copies of.

Generate a slice of an enormous specification

--include-path and --exclude-path generate only the operations you actually call. On something the size of Microsoft Graph, generating everything produces a client no compiler is pleased to see and no human wants to read. Kiota is the only tool here that treats the specification is enormous as the normal case rather than the edge case, and if your team calls four endpoints of a thousand-endpoint API, nothing else on this page handles that as gracefully.

Fluent request builders that mirror the URL

client.Users["id"].Messages.Get() reads like the path it calls. The point is predictability across APIs: once you know the shape, every Kiota client works the same way regardless of who wrote the specification. Voxgig makes the opposite bet, that entities and operations are a better level to work at than paths, which is why its CLI is myapi load myentity rather than a URL. Both are defensible. They suit different readers.

A large vendor pays for it, and you are still not locked in

MIT, on GitHub, maintained by Microsoft with the .NET and Graph ecosystems behind it. That combination is rare, and it is a serious answer to the longevity question that this field has had a bad year on.

Side by side#

No partial ticks and no asterisks. If a tool has a feature, the table says it has it. Where a row would need a paragraph to be true, it is a paragraph somewhere else on this page instead of a row here.

KiotaVoxgig
Whose problem it solvesThe team calling an APIThe team that owns the API
LicenceMITMIT
CostFreeFree
Language targets8, at varying maturity22 bundled language targets, more from packages
Generated codeThin, over installed `kiota-abstractions` packagesSelf-contained, no runtime dependency
Cross-cutting behaviourMiddleware in the shared abstractions, per language18 generated features, same options in every target
Partial generationYes, by path include and excludeWhole model
MCP server, CLI, REPLNoYes

Which one to choose#

Choose Kiota when

  • You are consuming somebody else's API and you want one client style and one HTTP stack across all of them.
  • The specification is enormous and you need a slice of it.
  • You are in .NET and want the ecosystem's own tool, maintained by the same company as the runtime.
  • You would rather configure retry and telemetry once in middleware than have it generated into each client.

Choose Voxgig when

  • You are the API provider and your customers will judge the library by how it reads and what it needs installed.
  • You want a self-contained SDK with no runtime dependency, because every dependency you add is one your customers' security teams will ask about.
  • You want retries, caching, idempotency, cost tracking and tracing as generated features with identical options in every language, rather than middleware each consumer assembles.
  • You need the MCP server, CLI, REPL or Agent Skills surfaces.

Limits of this comparison#

  • These two tools are not substitutes. Kiota is included because it is commonly shortlisted alongside the others, and that shortlist usually resolves on one question: whether you are consuming an API or publishing one.
  • Language maturity varies a lot across Kiota's targets. Check the support matrix for yours rather than trusting a count.
  • If you consume many APIs and also publish one, using both tools is a sensible answer and not a contradiction.

Corrections go to info@voxgig.com or an issue. A correction changes the page and moves its checked date; corrections from Kiota's own team carry the most weight.

Kiota documentation#

First-party sources for the claims on this page. Where they disagree with it, they are the authority.

Kiota documentationKiota on GitHub

The other comparisons#

  • OpenAPI GeneratorThe community generator most APIs have shipped an SDK from at least once.
  • SpeakeasyCommercial SDK generation with the widest non-SDK output in this comparison.
  • FernSDKs and a documentation site from one definition. Part of Postman since January 2026.
  • StainlessThe generator behind many of the best-known AI SDKs. Its hosted product is winding down.
  • APIMaticThe longest-running commercial generator here, and the only one that converts between description formats.
  • liblabSDK generation shaped as a release pipeline. Part of Postman since November 2025.
  • Hey APIThe TypeScript ecosystem's generator. One language, done properly.

All comparisons, the ground rules, and the wider field

Read the generated code#

The generator is MIT and open, and the catalog holds 600+ generated SDKs readable without installing anything.

Voxgig SDK GeneratorTalk to Voxgig

Get the Voxgig dispatch

Short notes on building SDKs, CLIs, REPLs, and MCPs for API-first teams, plus the occasional Fireside episode pick.

By signing up you agree to our Terms and Conditions.