SDK generator comparisons

Kiota and Voxgig, compared

A Microsoft client generator with a different scope from the rest of this field, and one teams shortlist alongside them anyway.

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. Every page in this section follows the same scope and method.

What Kiota is#

Kiota is an MIT-licensed command-line generator from Microsoft. It produces strongly typed, fluent API clients for eight targets: C#, Go, Java, PHP and Python at stable maturity, and Dart, Ruby and TypeScript in preview, by the support table in its README on the checked date. 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. That 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 an enormous specification as the normal case rather than the edge case. 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 without locking you 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
LicenseMITMIT
CostFreeFree
Language targets8: five stable, three in preview23 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack
Generated codeThin, over installed kiota-abstractions packagesSelf-contained, no runtime dependency
Cross-cutting behaviorMiddleware in the shared abstractions, per language20 generated features, same options in every target
Partial generationYes, by path include and excludeWhole model
CLI, MCP Server, REPLNoYes

One API, two SDKs#

Apicurio Registry publishes an SDK made with Kiota. Voxgig built one from the same definition, and both were run against a mock of that definition on the same four steps: list, load, create, and remove. Voxgig's features are in the build and stay off until a client switches them on; the rows describe them switched on. Last measured 29 September 2026.

Voxgig

voxgig-sdk/apicurio-registry-sdk

Built on 29 September 2026 from the same definition: eight targets from one run. A repository to build from, not a published package.

The definition: Apicurio Registry's own definition, openapi.json at tag 3.3.3 of Apicurio/apicurio-registry: OpenAPI 3.0.3, 82 paths, 132 operations, Apache 2.0. Its source.

What each SDK does

KiotaVoxgig
Operations callable132 methods132 of 132
Mock scenario on groups4 of 4 steps right, with request compression switched off as its README documents4 of 4 right
RetriesFrom Kiota's default middleware, not the SDKOn 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After
TimeoutsNone30 seconds per attempt by default
PaginationNone. Limit and offset by handPage and cursor state carried between calls in ctrl.paging, with no iterator
Idempotency keysNoneGenerated for every mutating call, and kept across its retries
Rate limitsWhatever Kiota's retry middleware does, not the SDKA client-side token bucket, and Retry-After honored on 429
LoggingNoneRequest and response logging, with auth headers redacted
Offline test modeNoneA mock transport seeded with your data, which the generated tests run on
MetricsKiota's own OpenTelemetry support in its request adapter, not the SDKPer-operation counts and timings, with no OpenTelemetry
CancellationNoneA signal stops stream() between items. Only the timeout aborts a request in flight
HooksKiota middleware, appended to the defaults or replacing themCustom features that hook every stage of a call
ErrorsMapped statuses resolve to ProblemDetails, and two of them to a rule-violation subclassOne error class per SDK, carrying the HTTP status and a notFound flag

What the code is

KiotaVoxgig
Package@apicurio/apicurio-registry-sdk on npmNot published. You build it from the repository
TypeScript package size0.64 MB in 115 files2.74 MB in 416 files
Runtime dependenciesNone, plus 6 Kiota peer packages you installNone
Languages from this buildTypeScriptTypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server
ShapeFluent request builders that mirror the path, such as client.groups.byGroupId(id).get()43 entities, such as Group, each with the list, load, create, update and remove operations the API has
TypesAn interface per model, with a generated serializer and deserializer for eachAn interface per entity, from the response schema, with nested objects typed any
TestsNot run here: the comparison used the published package509 generated TypeScript tests pass, as do the generated Go, Python, Ruby, Lua, and PHP suites

The same calls in each, in TypeScript. Both samples type-check under strict mode against the SDK they name.

@apicurio/apicurio-registry-sdk 3.3.3
import { RegistryClientFactory } from '@apicurio/apicurio-registry-sdk'

const client = RegistryClientFactory.createRegistryClient('https://registry.example.com/apis/registry/v3')

const page = await client.groups.get()
const group = await client.groups.byGroupId('payments').get()
const created = await client.groups.post({ groupId: 'payments' })
await client.groups.byGroupId('payments').delete()
voxgig-sdk/apicurio-registry-sdk
import { ApicurioRegistrySDK } from '@voxgig-sdk/apicurio-registry-sdk'

const client = new ApicurioRegistrySDK({ server: { registry: 'registry.example.com' } })

const groups = await client.Group().list()
const group = await client.Group().load({ id: 'payments' })
// GroupCreateData is the group response: it requires owner, createdOn,
// modifiedBy and modifiedOn, which the server assigns. Hence the cast.
const created = await client.Group().create({ groupId: 'payments' } as any)
await client.Group().remove({ id: 'payments' })

What building and running both found

  • Kiota's SDK gzips request bodies by default, which the mock could not read. Its README documents the opt-out, and the scenario used it.
  • Its retries, redirects and telemetry come from Kiota's middleware in the six peer packages rather than from generated code, which is why the package itself is small.
  • apidef took labels, the one object-valued property of the group schema, for an envelope until 8.18.0, so Voxgig's load and create returned the labels map. On 8.22.0 both return the group.
  • Voxgig's create type is the group response, so it requires owner, createdOn, modifiedBy, and modifiedOn, which the server assigns, and a TypeScript create needs a cast (voxgig/sdkgen#215).
  • The definition names no server, because the registry is self-hosted. apidef accepts that since 8.20.0, and the Voxgig build keeps the server the definition's own description states, so you pass your host as server.registry.
  • sdkgen sent every match field as a query parameter too until 4.31.0. On 4.32.1 a path parameter stays in the path, which a strict server needs.

The full scorecard, with the evidence for every row

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 CLI, MCP Server, Agent Skills or REPL surfaces.

Limits of this comparison#

  • These two tools are not substitutes. Teams shortlist Kiota 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.
  • The SDK pair is one API, compared in TypeScript against a mock of its definition. Kiota's side of it includes behavior from its shared abstraction packages, installed as peers, which is Kiota's design rather than an extra.

Corrections go to info@voxgig.com or an issue on the generator repository. 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.

The other comparisons#

  • OpenAPI GeneratorThe community generator most APIs have shipped an SDK from at least once.
  • SpeakeasyCommercial SDK generation whose generator became AGPL-3.0 open source in September 2026.
  • 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.
  • Cloudflare ForgeCloudflare's open-source generation pipeline, published on 28 September 2026.
  • 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, with a Python generator in early development.

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, MCP Servers, and REPLs for API-first teams, plus the occasional Fireside episode pick.

By signing up you agree to our Terms of use.