# Kiota and Voxgig, compared

> 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. Published by Voxgig, which makes one of the two tools. Facts checked 28 September 2026.

## What it 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.

## Facts

- Made by: Microsoft
- License: MIT
- Source: `github.com/microsoft/kiota` (https://github.com/microsoft/kiota)
- Cost: Free
- Built for: API consumers, at Microsoft Graph scale

## What Kiota does that Voxgig does not

### 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

| | Kiota | Voxgig |
| --- | --- | --- |
| Whose problem it solves | The team calling an API | The team that owns the API |
| License | MIT | MIT |
| Cost | Free | Free |
| Language targets | 8: five stable, three in preview | 23 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack |
| Generated code | Thin, over installed `kiota-abstractions` packages | Self-contained, no runtime dependency |
| Cross-cutting behavior | Middleware in the shared abstractions, per language | 20 generated features, same options in every target |
| Partial generation | Yes, by path include and exclude | Whole model |
| CLI, MCP Server, REPL | No | Yes |

## 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.

- Kiota: [`@apicurio/apicurio-registry-sdk 3.3.3`](https://github.com/Apicurio/apicurio-registry/tree/main/typescript-sdk). The TypeScript SDK Apicurio publishes on npm, generated with Kiota. Its source is the `typescript-sdk` directory of the registry repository.
- Voxgig: [`voxgig-sdk/apicurio-registry-sdk`](https://github.com/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. Source: https://github.com/Apicurio/apicurio-registry

### What each SDK does

| | Kiota | Voxgig |
| --- | --- | --- |
| Operations callable | 132 methods | 132 of 132 |
| Mock scenario on groups | 4 of 4 steps right, with request compression switched off as its README documents | 4 of 4 right |
| Retries | From Kiota's default middleware, not the SDK | On 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After |
| Timeouts | None | 30 seconds per attempt by default |
| Pagination | None. Limit and offset by hand | Page and cursor state carried between calls in `ctrl.paging`, with no iterator |
| Idempotency keys | None | Generated for every mutating call, and kept across its retries |
| Rate limits | Whatever Kiota's retry middleware does, not the SDK | A client-side token bucket, and Retry-After honored on 429 |
| Logging | None | Request and response logging, with auth headers redacted |
| Offline test mode | None | A mock transport seeded with your data, which the generated tests run on |
| Metrics | Kiota's own OpenTelemetry support in its request adapter, not the SDK | Per-operation counts and timings, with no OpenTelemetry |
| Cancellation | None | A signal stops `stream()` between items. Only the timeout aborts a request in flight |
| Hooks | Kiota middleware, appended to the defaults or replacing them | Custom features that hook every stage of a call |
| Errors | Mapped statuses resolve to ProblemDetails, and two of them to a rule-violation subclass | One error class per SDK, carrying the HTTP status and a `notFound` flag |

### What the code is

| | Kiota | Voxgig |
| --- | --- | --- |
| Package | `@apicurio/apicurio-registry-sdk` on npm | Not published. You build it from the repository |
| TypeScript package size | 0.64 MB in 115 files | 2.74 MB in 416 files |
| Runtime dependencies | None, plus 6 Kiota peer packages you install | None |
| Languages from this build | TypeScript | TypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server |
| Shape | Fluent 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 |
| Types | An interface per model, with a generated serializer and deserializer for each | An interface per entity, from the response schema, with nested objects typed `any` |
| Tests | Not run here: the comparison used the published package | 509 generated TypeScript tests pass, as do the generated Go, Python, Ruby, Lua, and PHP suites |

The same calls in each, in TypeScript. `@apicurio/apicurio-registry-sdk 3.3.3`:

```ts
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`:

```ts
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](https://github.com/voxgig/sdkgen/issues/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: https://github.com/voxgig-sdk/apicurio-registry-sdk/blob/main/COMPARISON.md

## 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. A correction changes the page and moves its checked date.

## First-party sources

- [Kiota documentation](https://learn.microsoft.com/openapi/kiota/)
- [Kiota on GitHub](https://github.com/microsoft/kiota)

## The other comparisons

- [All SDK generator comparisons](https://voxgig.com/sdk/comparisons): the index, the method, and the wider field.
- [OpenAPI Generator](https://voxgig.com/sdk/comparisons/openapi-generator): The community generator most APIs have shipped an SDK from at least once.
- [Speakeasy](https://voxgig.com/sdk/comparisons/speakeasy): Commercial SDK generation whose generator became AGPL-3.0 open source in September 2026.
- [Fern](https://voxgig.com/sdk/comparisons/fern): SDKs and a documentation site from one definition. Part of Postman since January 2026.
- [Stainless](https://voxgig.com/sdk/comparisons/stainless): The generator behind many of the best-known AI SDKs. Its hosted product is winding down.
- [Cloudflare Forge](https://voxgig.com/sdk/comparisons/cloudflare-forge): Cloudflare's open-source generation pipeline, published on 28 September 2026.
- [APIMatic](https://voxgig.com/sdk/comparisons/apimatic): The longest-running commercial generator here, and the only one that converts between description formats.
- [liblab](https://voxgig.com/sdk/comparisons/liblab): SDK generation shaped as a release pipeline. Part of Postman since November 2025.
- [Hey API](https://voxgig.com/sdk/comparisons/hey-api): The TypeScript ecosystem's generator, with a Python generator in early development.
- [Voxgig SDK Generator](https://voxgig.com/sdk)