Kiota: generating typed HTTP clients from OpenAPI descriptions

The dependency problem Kiota is built to remove

Most teams that call several HTTP APIs end up with several client libraries. One service ships a .NET SDK, another only documents its endpoints, a third has a Python package that lags the API. Each library has its own authentication model, its own retry behaviour and its own idea of how a request is built. The README states the goal directly: to eliminate the need to take a dependency on a different API SDK for every API that you need to call.

Kiota's answer is to generate the client from the OpenAPI description instead of consuming a vendor's SDK. The generated code is described as providing a strongly typed experience with all the features you expect from a high quality API SDK, without having to learn a new library for every HTTP API. The intended user is a developer who already has an OpenAPI description in hand and wants a callable client in their own language, not a new runtime to learn.

The project builds on Microsoft.OpenAPI.NET for parsing, and one stated goal is to provide the best code generator support possible for OpenAPI and JSON Schema features. That is a narrower ambition than it sounds: the quality of the generated client is bounded by how completely your description expresses the API.

How generation works and what the generated client depends on

The repository is organised as a generator plus a set of per-language runtime components. The top level contains abstractions/, authentication/, http/ and serialization/ directories alongside src/, which is where the generator itself lives. The generated client is not standalone: it references runtime packages that implement the abstractions, the HTTP transport and the serializers in the target language.

The README's support table makes that split explicit. For C#, generation is complete, and the abstractions, HTTP and serialization components are split into form, JSON, multipart and text, each in its own repository (kiota-dotnet). Authentication providers listed for C# are anonymous, API key and Azure. Go and Java follow the same shape with their own repositories (kiota-abstractions-go, kiota-java), and Go's HTTP support lives in kiota-http-go.

This is the part worth understanding before adopting. Kiota generates a client that is fluent and typed, but the behaviour at runtime (how JSON is deserialized, how a request is sent, how a token is attached) comes from packages you also take a dependency on. The table is the authoritative list of what exists per language. Dart, for example, is marked with the in-progress symbol across generation, abstractions, serialization and HTTP, so a Dart client is not at the same level as C# or Go.

Installing Kiota and generating your first client

The README does not inline install commands. It points to the install page at learn.microsoft.com/openapi/kiota/install, which lists the available options, and the quickstart links per language. What the repository does contain is a Dockerfile, so the container path is verifiable from the repository itself.

The image builds the generator with the .NET 10 SDK and runs it on a chiseled runtime image. It declares three volumes and one environment variable:

VOLUME /app/output
VOLUME /app/openapi.yaml
VOLUME /app/apimanifest.json
ENV KIOTA_CONTAINER=true DOTNET_TieredPGO=1 DOTNET_TC_QuickJitForLoops=1
ENTRYPOINT ["dotnet", "kiota.dll"]

The entrypoint means the container behaves like the kiota executable: arguments you pass go to the CLI. The volumes indicate the expected workflow, mounting your description at /app/openapi.yaml and a directory at /app/output for the generated code. The KIOTA_CONTAINER variable is set for you, so container-aware behaviour in the tool is switched on without extra configuration.

Once Kiota is installed by whichever option you chose on the install page, generation follows the four steps the README lists: install the required tools and dependencies for your target language (the table's Required tools & dependencies column), get Kiota, generate the API client using the parameters reference, then start calling the API with the fluent client. The parameters reference lives at learn.microsoft.com/openapi/kiota/using and is where the generation flags are documented; the README does not reproduce them.

A practical first run is therefore: pick a language whose row in the support table shows complete generation, install that language's toolchain, generate against a small OpenAPI file, and confirm the generated project resolves the abstractions and serialization packages named in the table. If those packages do not resolve, the problem is the runtime side, not the generator.

Where Kiota is the wrong choice

The clearest limitation is in the support table itself. Languages marked with the in-progress symbol have incomplete abstractions, serialization or HTTP components. Dart is marked that way throughout, with only anonymous and API key authentication listed. If your target is Dart, the README does not claim parity with C#, Go, Java or the other completed languages, and you should treat generation there as unfinished work rather than a supported path.

A second boundary is the OpenAPI description. Kiota generates from a description, so anything the description omits cannot appear in the client. The README frames the project's ambition as generator support for OpenAPI and JSON Schema features, which is an admission that feature coverage is the hard part. A hand-written SDK can encode behaviour that was never written down; a generated one cannot.

Third, Kiota is a command line tool, not a library you call from your build. That matters if you wanted to run generation inside an application or a custom pipeline step in-process. The README's own description of the project is a command line tool for generating an API client, and the container entrypoint reinforces that shape.

Finally, regeneration is a build-time commitment. The README does not document how to merge generated code with hand edits, and it does not describe a rollback path for a bad generation. If your team routinely patches generated files by hand, that practice sits outside anything the README describes.

Kiota compared with OpenAPI Generator and Swagger Codegen

The obvious comparison is OpenAPI Generator, and the difference is architectural rather than a matter of language counts. OpenAPI Generator emits a self-contained client per language from templates. Kiota emits a client that depends on a shared set of runtime packages (abstractions, HTTP, serialization, authentication) maintained per language in separate repositories. That means a Kiota client is thinner, because request building and serialization are not regenerated each time, but it also means generation and runtime versions have to move together.

Swagger Codegen belongs to the same template-driven family as OpenAPI Generator. Kiota's stated goal is different in kind: the README says it builds on Microsoft.OpenAPI.NET to ensure comprehensive support for APIs that use OpenAPI descriptions, and that one of the project's goals is the best possible code generator support for OpenAPI and JSON Schema features. That is a claim about parsing and feature fidelity, not about the number of output targets.

The practical test is what you want to own. If you want a client you can vendor and modify without a runtime dependency, a template-driven generator is the closer fit. If you want a consistent, typed calling experience across several APIs and languages, and you accept the runtime packages, Kiota's model is the one that was designed for it.

Releases, licence and what a version bump costs you

Kiota is MIT licensed, which permits commercial use and modification; the LICENSE file is at the repository root. That is a statement about the licence text, not advice about your situation, and the per-language runtime repositories carry their own licences that you should read separately.

Release cadence is visible from the tags. v1.29.1 was tagged on 2026-08-14, v1.35.0 on 2026-09-04, and v1.35.0-preview.202609100001 on 2026-09-10. The last push to the default branch was on 2026-09-23. The project is not archived, and the repository ships a CHANGELOG.md at the top level, which is where you should look before upgrading.

The upgrade cost has two parts. The generator is a CLI, so updating it is a tool install. The generated client, however, references the per-language runtime packages listed in the support table. A generator upgrade that changes emitted code can require a matching runtime package upgrade, and the README does not describe a compatibility matrix between generator versions and runtime package versions. That gap is the thing to check first when planning an upgrade: read CHANGELOG.md, then regenerate into a scratch directory and diff before replacing the code you build against.

Editorial conclusion

Adopt Kiota when you call several OpenAPI described APIs and want one generation workflow plus per-language runtime packages instead of a hand-written client per service, and when your API description is stable enough to regenerate from. Do not adopt it if your target language is Dart, which the README marks with the in-progress symbol, or if you need the generator itself to be a library you embed, since the README presents it as a command line tool. Before committing, generate against your own OpenAPI file and confirm the generated abstractions and serialization packages exist for your language, then check the CHANGELOG.md for breaking changes between v1.29.1 and v1.35.0.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/kiota on GitHub
3. Project website
4. README
5. Releases