Kiota vs NSwag vs Refitter in .NET: Which Typed API Client Generator Should Your Team Use in 2026?

Every modern .NET team eventually faces the same decision: how do you generate and maintain typed HTTP clients from an OpenAPI specification without drowning in boilerplate? The three tools that dominate this space in 2026 — Kiota, NSwag, and Refitter — each solve the problem from a fundamentally different angle, and picking the wrong one creates maintenance headaches that compound over time. The concepts covered here go deeper on Patreon — with annotated, production-ready examples that map directly to what enterprise teams actually ship when consuming internal and third-party APIs.

Understanding the tradeoffs between these generators isn't just a tooling preference — it shapes how your team handles versioning, authentication injection, resilience policies, and build pipeline complexity. Understanding how typed API client generation fits into the bigger picture of a production-ready ASP.NET Core API — particularly around IHttpClientFactory integration, Polly resilience, and handler pipelines — is exactly what Chapter 1 and Chapter 10 of the Zero to Production course walk through with a complete working codebase.

What Is Typed API Client Generation, and Why Does It Matter?

Typed API client generation takes an OpenAPI (Swagger) specification and produces strongly-typed C# classes and interfaces that let you call remote APIs as if they were local method invocations. Instead of manually constructing HttpRequestMessage objects, parsing JSON, and mapping status codes, you get a generated client that handles all of that — with full IntelliSense support and compile-time safety.

The business case for using a generator rather than hand-rolling clients is straightforward: API contracts change, and when they do, regenerating a client catches breaking changes at compile time rather than at runtime in production. For teams consuming more than a handful of internal or third-party APIs, client generation becomes a non-negotiable part of the build pipeline.

The Three Contenders: A Brief Overview

Kiota — Microsoft's Official OpenAPI Client Generator

Kiota is Microsoft's own typed client generator, built to support the full breadth of the OpenAPI specification and designed for use across multiple programming languages. In the .NET ecosystem, it generates fluent-style clients that closely mirror the API's URL path structure. Kiota is actively maintained by Microsoft and is the generator behind the Microsoft Graph SDK.

Its philosophy is path-first navigation: instead of calling client.GetProductAsync(id), you call client.Products[id].GetAsync(). This maps directly to the OpenAPI path hierarchy, which makes it natural for large API surfaces but can feel verbose for simple APIs.

Kiota ships as a .NET tool (dotnet tool install microsoft.openapi.kiota) and generates a full set of models, request builders, and a strongly-typed navigation tree.

NSwag — The Mature, Highly Configurable Workhorse

NSwag has been the go-to OpenAPI toolchain for .NET developers for years. It handles both directions: it can generate OpenAPI specs from your ASP.NET Core controllers, and it can generate C# clients from an existing OpenAPI document. It supports both HttpClient-based clients and Refit-style interfaces out of the box.

NSwag is highly configurable via .nswag configuration files, MSBuild integration, or the NSwagStudio UI. Its code generation is template-driven, meaning you can customise virtually every aspect of the generated output — at the cost of configuration complexity.

Refitter — Source Generator–Powered Refit Interfaces

Refitter takes a different approach: instead of generating a full client implementation, it generates a Refit interface from an OpenAPI spec. You get an interface like IProductsApi with [Get("/products/{id}")] attributes, and Refit handles the HTTP plumbing at runtime. Refitter can operate as a Roslyn source generator (build-time, no explicit generation step) or as a .NET tool for explicit generation.

The key differentiator is that Refitter leans on Refit's existing ecosystem for authentication handlers, resilience policies via IHttpClientFactory, and serialisation — it generates the interface contract, not the implementation.

Side-by-Side Comparison

Generation Approach

Developer Experience

Kiota produces a navigable object tree that mirrors the API's URL structure. For teams consuming Microsoft APIs (Graph, Azure Resource Manager), this is the natural choice — the generated code is consistent with the SDKs your team already knows. For internal APIs, the path-first style can feel over-engineered, especially for small API surfaces.

NSwag generates flat, method-per-operation clients. The output is immediately familiar — await client.GetProductAsync(id, cancellationToken) — and easy to test with Moq or NSubstitute by wrapping the generated class in an interface. The configuration surface is large, which is both its strength (full control) and its weakness (steep learning curve and .nswag files that need careful maintenance).

Refitter produces the lightest output and the most idiomatic integration with IHttpClientFactory. Because Refitter generates an interface rather than a class, DI registration is a single services.AddRefitClient<IProductsApi>() call, resilience policies attach naturally via Polly, and the pattern scales across large codebases without the generated code feeling foreign.

How Does Each Handle Authentication?

This is where the three tools diverge most in practice.

With Kiota, authentication is handled via IAuthenticationProvider, a Kiota-specific abstraction. Microsoft ships providers for Bearer tokens and API keys, but custom schemes require implementing the interface. The authentication is baked into the request builder, which works well for Microsoft-hosted APIs but can feel coupled when you have dynamic token sources.

With NSwag, authentication is injected via a custom DelegatingHandler registered on the underlying HttpClient. This is the standard .NET pattern — your existing handler code works unchanged.

With Refitter, authentication is handled identically to any Refit client: AddRefitClient<IProductsApi>().ConfigureHttpClient(c => c.DefaultRequestHeaders.Authorization = ...) or via a delegating handler. Since Refitter just generates the interface, your entire authentication, retry, and header-manipulation logic stays in the standard IHttpClientFactory pipeline.

Build Pipeline Integration

NSwag and Kiota both support MSBuild-triggered generation, meaning the client is regenerated every time the spec changes on build. This works well but adds build time and requires the spec to be available at build time (local file or URL).

Refitter as a source generator is the cleanest option for build pipeline integration: the interface is generated as part of the Roslyn compilation step, there is no separate tool invocation, and partial class support lets you add hand-written extensions without touching generated files. The downside is that source generator debugging is harder and the generated code isn't checked into source control by default.

Refitter as a .NET tool (explicit generation) lets you commit generated files to source control — useful when you want diffs on API contract changes reviewed in pull requests.

When to Use Each Tool

Use Kiota When:

• You are consuming Microsoft Graph, Azure APIs, or any Microsoft-hosted API where the SDK is already Kiota-based
• Your team works across multiple languages and wants a single generator for TypeScript, Python, Java, and .NET clients
• The API surface is large and hierarchical (100+ endpoints) and the path-first navigation model genuinely helps discovery
• You are building an SDK for external developers and want the same generator as Microsoft uses

Use NSwag When:

• You need maximum configurability — custom templates, specific client patterns, or code generation for both server and client from the same tool
• Your team is already invested in NSwag for server-side spec generation and adding client generation is a low-friction extension
• You are consuming an older API with OpenAPI 2.0 (Swagger) specs, where Kiota and Refitter support is less mature
• You want a self-contained generated client with no additional runtime dependencies

Use Refitter When:

• Your team uses Refit already and wants to auto-generate the interface contracts rather than write them by hand
• You want the tightest IHttpClientFactory integration — delegating handlers, Polly policies, and typed clients all wire together without any adapter layer
• You are using a source generator workflow and want zero explicit build steps for client regeneration
• The API surface is small to medium and you value minimal, readable generated code over rich runtime abstractions

Real-World Trade-Offs

Generated code ownership is the sharpest edge. NSwag gives you the most generated code — and the most code to own when the generator produces something unexpected. Kiota abstractions are stable but opaque; you're trusting Microsoft's abstraction layer. Refitter generates almost nothing — just an interface — which means there is very little generated code to reason about.

OpenAPI 3.1 compliance matters if you are working with modern APIs that use discriminated unions, $ref to external schemas, or oneOf/anyOf extensively. Kiota and Refitter have better 3.1 support in 2026; NSwag's 3.1 support is partial and can produce incorrect models for complex schemas.

Team onboarding is fastest with Refitter if the team already knows Refit. The generated interface looks exactly like what a developer would write by hand — there is no new mental model to learn. Kiota requires understanding request builders, and NSwag's configuration surface needs dedicated learning time.

The Recommendation

For most ASP.NET Core teams consuming internal microservice APIs or well-defined third-party APIs, Refitter is the default choice in 2026. It generates the least code, integrates with the most .NET-idiomatic patterns, and requires no runtime dependency beyond Refit itself. The learning curve is flat for any team already using typed clients.

Kiota is the right answer when you are consuming Microsoft's own API surface or building multi-language SDKs. Its investment in standards compliance and Microsoft Graph parity makes it the natural choice for that context.

NSwag holds its ground for teams that need to generate both the spec and the client from a single tool, or for projects on older OpenAPI 2.0 specs where the alternatives offer incomplete support.

The worst outcome is mixing all three in the same repository without a clear rationale — which is exactly what happens when the decision gets made separately by each team. Establish a standard, pick the tool that fits your predominant use case, and apply it consistently.

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

Frequently Asked Questions

What is the difference between Kiota, NSwag, and Refitter?

Kiota is Microsoft's official multi-language OpenAPI client generator that produces path-based fluent clients. NSwag is a mature .NET toolchain that generates both OpenAPI specs from controllers and C# clients from specs, with high configurability. Refitter generates Refit interfaces from OpenAPI specs, delegating all HTTP execution to the Refit library. The core difference is in the output style and runtime model: Kiota ships its own abstraction layer, NSwag produces self-contained clients, and Refitter produces only the interface contract.

Which typed API client generator has the best ASP.NET Core IHttpClientFactory support?

Refitter has the most natural IHttpClientFactory integration because it generates a Refit interface, and Refit's AddRefitClient<T>() extension is built on top of IHttpClientFactory. This means Polly resilience handlers, delegating handlers for authentication, and typed client lifetimes all work exactly as documented by Microsoft. NSwag clients require wrapping in an interface and injecting the underlying HttpClient manually.

Does Kiota support OpenAPI 3.1?

Yes. Kiota has been actively improving its OpenAPI 3.1 support and as of 2026 handles most 3.1 schema constructs including oneOf, anyOf, and external $ref resolution. NSwag's 3.1 support is partial and may produce incorrect or incomplete models for schemas that use 3.1-specific features. Refitter's 3.1 support depends on the underlying spec parsing library but has seen significant improvements in recent versions.

Can I use Refitter without Refit?

No. Refitter generates Refit interface attributes ([Get], [Post], etc.), so the generated code has a compile-time dependency on the Refit package. If you do not want a runtime Refit dependency, use NSwag (which generates a self-contained HttpClient-based client) or Kiota (which depends only on its own abstraction packages).

Which tool is best for consuming Microsoft Graph API?

Kiota is the correct choice for Microsoft Graph. Microsoft Graph SDK itself is built on Kiota, the client generation is officially supported and kept in sync with the API surface, and authentication providers for Microsoft Identity (MSAL, managed identity, client credentials) are available as first-party packages. Using NSwag or Refitter to generate a Graph client would mean maintaining your own spec conversion and losing Microsoft's testing and versioning guarantees.

Should I commit generated API client code to source control?

It depends on the tool and your team's preferences. With Refitter as a source generator, generated code does not exist as files and cannot be committed — which keeps the repository clean but makes API contract diffs invisible in pull requests. With NSwag or Refitter as a .NET tool, you can commit generated files and get meaningful diffs when the API spec changes. For teams that want explicit review of API contract changes, committing generated files and running generation as part of CI to detect drift is the recommended pattern.

How does NSwag compare to AutoRest in 2026?

AutoRest is deprecated by Microsoft and is scheduled for retirement in mid-2026. For new projects, NSwag, Kiota, and Refitter are the viable options. NSwag is the closest functional replacement for AutoRest's C#-focused use cases, while Kiota replaces AutoRest for multi-language SDK generation scenarios.