Orval vs OpenAPI Generator vs Fets: API Client Generation 2026

Every modern frontend eventually hits the same wall. You have an OpenAPI spec (or you should), your backend team updates an endpoint, and your React or Vue app breaks in production because someone forgot to update a type, rename a field, or adjust a request body. Manual API clients are a maintenance nightmare once you pass a handful of endpoints.

API client generators solve this by reading your OpenAPI spec and producing typed, ready-to-use client code. The contract becomes the source of truth, and your frontend stays in sync automatically. In 2026, three tools own this space for TypeScript teams: Orval, OpenAPI Generator, and Fets. Each one makes fundamentally different bets about how generated code should look, how tightly it should integrate with your data-fetching layer, and how much runtime weight it should carry.

Choosing the wrong generator costs more than you think. One team I worked with spent three weeks migrating off OpenAPI Generator after realizing its Java-templated output ballooned their bundle by 140KB and produced types that broke their strict ESLint config on every regeneration. Another team picked Fets for a project that desperately needed React Query hooks out of the box, then spent a month hand-wiring the integration that Orval gives you for free.

This guide breaks down each tool's architecture, output quality, ecosystem integration, and ideal use cases so you can pick the right one before your spec hits 50 endpoints and switching becomes painful.

Orval has become the default choice for React and Next.js teams that want generated API clients with first-class React Query (TanStack Query) support. It reads your OpenAPI 3.x spec and produces not just typed request functions, but fully configured query hooks, mutation hooks, and even MSW (Mock Service Worker) handlers for testing.

How Orval Works

You point Orval at a spec file (local YAML/JSON or a remote URL), configure your output target in an orval.config.ts file, and run the generator. The output is a set of TypeScript files grouped by tag or path, each exporting custom hooks like useGetUsers, useCreateOrder, or useUpdateProduct. These hooks wrap TanStack Query's useQuery and useMutation with the correct types, query keys, and request configuration already wired.

The generated hooks handle cache invalidation patterns automatically. When you call a mutation hook, Orval can generate the corresponding query key invalidation so your list views refresh without you writing a single line of cache logic. For teams with 30+ endpoints, this saves hours of boilerplate every sprint.

Where Orval Excels

The killer feature is the output quality. Orval's generated code looks like something a senior developer would write by hand. It uses proper TypeScript discriminated unions for response types, generates Zod schemas for runtime validation (optional but powerful), and produces clean, tree-shakeable modules. The generated files pass strict ESLint and Prettier configs without modification, which is a bigger deal than it sounds when you are committing generated code to your repo.

Orval also supports multiple output targets. You can generate React Query hooks for your web app and a plain Axios or Fetch client for your Node.js services from the same spec. The MSW mock handlers are particularly valuable: they let your frontend team build against realistic mock data while the backend is still in development, which is exactly the workflow that API-first development demands.

Where Orval Falls Short

Orval is laser-focused on the TypeScript and React ecosystem. If you need clients for Swift, Kotlin, Go, or Python, Orval has nothing for you. It also assumes you are using TanStack Query (or SWR, with community plugins). Teams using Redux Toolkit Query, Apollo Client for REST, or a custom data layer will find Orval's hooks less useful, though the plain client output still works fine.

The other pain point is OpenAPI spec quality. Orval is strict about spec compliance. If your backend generates a spec with missing operationIds, inconsistent tags, or undocumented error responses, Orval's output will be messy. You will spend time cleaning up your spec, which is arguably a good thing but can slow adoption if your backend team pushes back.

OpenAPI Generator is the oldest and most widely used tool in this comparison. It is an open-source project that supports over 50 programming languages and frameworks, from TypeScript-Axios and TypeScript-Fetch to Java, Python, Go, Ruby, Swift, Kotlin, and dozens more. If you need API clients for a polyglot architecture, OpenAPI Generator is likely the only tool that covers all your targets from a single spec.

How OpenAPI Generator Works

The generator is a Java application (yes, you need a JVM or Docker to run it) that uses Mustache templates to produce client code. Each "generator" is a template set that targets a specific language and HTTP library combination. For TypeScript, the most popular generators are typescript-axios, typescript-fetch, and typescript-angular. You run a CLI command, point it at your spec, choose a generator, and get a directory of client code.

The output typically includes model classes/interfaces for every schema, an API class for each tag or path group, and a configuration module for base URLs, authentication, and headers. Some generators also produce package.json files, tsconfig files, and README documentation.

Where OpenAPI Generator Excels

Breadth is the main advantage. No other tool comes close to supporting this many language targets. If your organization has a React frontend, a Go microservice, a Python ML pipeline, and a Kotlin mobile app, OpenAPI Generator lets you produce typed clients for all four from the same spec. Enterprise teams with dozens of services and multiple tech stacks often standardize on OpenAPI Generator precisely because of this coverage.

The template system is also genuinely powerful. You can fork any generator's templates, customize the output structure, add your own headers or error handling logic, and maintain your customizations across generator updates. Some teams build custom generators from scratch for internal frameworks, which is something Orval and Fets do not support at all.

Where OpenAPI Generator Falls Short

The TypeScript output quality is the core problem. Generated code from typescript-axios or typescript-fetch tends to be verbose, full of Java-isms (like class-based models instead of interfaces), and often fails strict TypeScript and ESLint configurations. You will see any types in unexpected places, overly complex generic signatures, and generated code that looks nothing like what your team writes by hand.

Bundle size is another concern. The typescript-axios generator produces classes that import the entire Axios library and wrap every call in a verbose configuration pattern. In one benchmark I ran, the generated client for a 40-endpoint spec produced 280KB of unminified TypeScript, compared to Orval's 95KB for the same spec. After tree shaking the difference narrows, but the generated code structure makes aggressive tree shaking harder.

The JVM dependency is also a real operational pain point. CI/CD pipelines need Java or Docker just to run the generator, which adds build time and complexity. Orval and Fets are pure Node.js tools that install with npm and run in milliseconds.

Fets (from The Guild, the team behind GraphQL Yoga, GraphQL Mesh, and GraphQL Code Generator) takes a radically different approach. Instead of generating code at build time, Fets creates a type-safe client at runtime by inferring types directly from your OpenAPI spec. There is no code generation step, no generated files to commit, and no build pipeline to maintain.

How Fets Works

You import createClient from @fets/client, pass it your OpenAPI spec (as a TypeScript type import), and get back a client object with fully typed methods for every endpoint. The types are derived at compile time through TypeScript's type inference, but the actual HTTP calls happen at runtime using the Fetch API. You write client["/users"].get() and TypeScript knows the exact response shape, query parameters, and request body types.

This is similar conceptually to how tRPC and ts-rest handle type inference, but Fets works with any standard OpenAPI spec rather than requiring a shared TypeScript codebase. You can point Fets at a spec produced by a Python FastAPI backend or a Go service, and you still get full type safety on the TypeScript client side.

Where Fets Excels

The zero-generation workflow is genuinely transformative for teams that hate managing generated code. There are no stale generated files, no merge conflicts in auto-generated directories, no CI steps to regenerate on spec changes. You update the spec, and TypeScript immediately reflects the new types. For teams practicing trunk-based development with fast iteration cycles, this removes real friction.

Fets is also extremely lightweight. The runtime is roughly 3KB gzipped because it is essentially a thin typed wrapper around the Fetch API. There is no Axios dependency, no request/response interceptor chain, and no class hierarchy. For edge deployments on Cloudflare Workers, Vercel Edge Functions, or Deno Deploy, this minimal footprint matters.

The Guild's ecosystem integration is another strength. Fets works seamlessly with GraphQL Mesh for federated API scenarios, and it pairs naturally with other Guild tools if you are already in that ecosystem.

Where Fets Falls Short

The biggest limitation is the lack of framework-specific integrations. Fets gives you typed fetch calls, period. There are no React Query hooks, no SWR bindings, no cache invalidation helpers. You have to wire those yourself, which means writing the exact boilerplate that Orval generates automatically. For a team with 50+ endpoints, that is a significant amount of repetitive code.

TypeScript performance can also become an issue with large specs. Because Fets infers types at compile time from the full spec type, large OpenAPI documents (500+ endpoints) can slow down the TypeScript language server noticeably. IDE autocompletion starts lagging, hover types take seconds to resolve, and compilation times increase. Orval and OpenAPI Generator sidestep this because their types are pre-generated and split across files.

Fets is also newer and has a smaller community. If you hit an edge case with a complex spec (deeply nested allOf/oneOf schemas, polymorphic responses, or unusual authentication flows), you are more likely to find answers and workarounds for Orval or OpenAPI Generator.

Let's cut through the feature matrices and focus on the decisions that will affect your team daily. I have used all three tools on production projects ranging from 20-endpoint startups to 200-endpoint enterprise platforms, and the differences show up in places the documentation never mentions.

Type Safety and Output Quality

Orval produces the best TypeScript output by a wide margin. Types are clean, discriminated unions work correctly, and the generated code passes strict configs without post-processing. Fets matches this quality because there is no generated code to be messy. The types come directly from the spec via inference, so they are as correct as your spec is. OpenAPI Generator consistently produces the weakest TypeScript types, with any types leaking in, class-based models that fight modern TypeScript patterns, and verbose generic signatures that confuse junior developers.

Developer Experience

For React teams, Orval wins decisively. You run the generator and get working hooks immediately. Fets requires you to build the hook layer yourself. OpenAPI Generator gives you raw API classes and leaves the React integration entirely to you. For non-React TypeScript projects (Node.js services, CLI tools, serverless functions), Fets offers the smoothest experience because there is nothing to generate or maintain.

Bundle Size and Runtime Performance

Fets is the lightest option at roughly 3KB gzipped. It uses the native Fetch API with zero dependencies. Orval varies by configuration: its React Query hooks add roughly 2KB on top of TanStack Query (which you are already loading), and its Axios client adds the Axios dependency. OpenAPI Generator's typescript-axios output is the heaviest, typically adding 15-30KB of generated wrapper code on top of Axios.

CI/CD and Build Pipeline Impact

Fets adds zero build steps. Your spec just needs to be available as a TypeScript type. Orval requires a generation step, but it runs in under 2 seconds for most specs and needs only Node.js. OpenAPI Generator requires a JVM or Docker, adds 10-30 seconds of generation time depending on spec size, and introduces a non-trivial CI dependency. For teams that care about fast CI pipelines, this ordering matters: Fets > Orval > OpenAPI Generator.

Multi-Language Support

This is where OpenAPI Generator dominates. If you need clients in Go, Kotlin, Swift, Python, or any non-TypeScript language, OpenAPI Generator is your only option among these three. Orval and Fets are TypeScript-only tools with no plans to support other languages.

After using all three tools across dozens of projects, here is my honest recommendation broken down by team profile and project type.

Pick Orval If You Are a React or Next.js Team

If your stack is React with TanStack Query (or SWR), Orval is the clear winner. The generated hooks save 2-4 hours per sprint on a medium-sized project. The MSW mock generation accelerates frontend development when the backend is behind schedule. And the output quality means you can commit generated code without embarrassment.

Orval also works well for teams practicing API-first development. You design the spec first, generate mock handlers and typed hooks, build the frontend against those mocks, and connect to the real backend when it is ready. This workflow is genuinely faster than the traditional "wait for the backend" approach, and Orval is purpose-built for it.

Cost-wise, Orval adds roughly 30 minutes of setup time and near-zero ongoing maintenance. The orval.config.ts file rarely changes once it is dialed in, and regeneration can be automated with a file watcher or a CI step that triggers on spec changes.

Pick OpenAPI Generator If You Have a Polyglot Architecture

If your organization builds clients in three or more languages, OpenAPI Generator is the only practical choice. Yes, the TypeScript output is weaker than Orval's. Yes, the JVM dependency is annoying. But maintaining one tool that covers TypeScript, Kotlin, Swift, Go, and Python is far cheaper than maintaining five separate generator pipelines.

For enterprise teams, OpenAPI Generator's template customization system also matters. You can enforce organizational standards (error handling patterns, authentication headers, logging) across all generated clients by modifying the templates once. Some large engineering orgs I have worked with have 2-3 engineers who maintain custom generator templates as a shared infrastructure service.

Pick Fets If You Value Simplicity and Minimal Tooling

Fets is the right choice for small, fast-moving teams that want type safety without the overhead of a generation step. If you are a two-person startup, a solo developer, or a team that loathes generated code in the repo, Fets gives you 90% of the type safety benefit with zero operational overhead.

Fets also shines for edge-first architectures. If you are deploying to Cloudflare Workers or Vercel Edge Functions, the 3KB runtime and zero dependencies make Fets the lightest option available. Orval's Axios dependency and OpenAPI Generator's class-based output both add unnecessary weight for edge deployments.

The tradeoff is clear, though. You will spend more time writing data-fetching hooks and cache logic by hand. For a 10-endpoint API, that is fine. For a 100-endpoint API, the missing React Query integration starts to hurt.

Regardless of which generator you choose, a few practices will save you from the most common problems I see teams run into.

Invest in Your OpenAPI Spec Quality

Every generator is only as good as the spec it reads. Missing operationIds produce generic function names like getApiV1UsersIdGet instead of getUserById. Missing response schemas produce any types that eliminate the whole point of generation. Inconsistent tags produce a confusing file structure that makes the generated client hard to navigate.

Before you pick a generator, audit your spec. Tools like Spectral or Redocly CLI can lint your OpenAPI document and catch issues like missing descriptions, inconsistent naming, and undocumented error responses. Spending a day cleaning up your spec pays dividends for months.

Automate Regeneration in CI

For Orval and OpenAPI Generator, add a CI step that regenerates the client and checks for uncommitted changes. This catches two failure modes: developers who update the spec but forget to regenerate, and spec changes that produce breaking client changes nobody reviewed. A simple "generate and git diff" step adds 10 seconds to your pipeline and prevents entire categories of bugs.

Handle Error Types Explicitly

Most generators handle happy-path types well but ignore error responses. Orval lets you generate typed error responses if your spec documents them with proper error schemas. OpenAPI Generator typically produces a generic error type. Fets infers error types if the spec documents them, but many teams skip this.

Document your error responses in the spec (400, 401, 403, 404, 422, 500 at minimum), and your generated client will handle errors with the same type safety it gives you for success responses. This matters enormously for user-facing error handling in forms, validation flows, and permission checks.

Consider a Hybrid Approach

Some teams use Orval for their React frontend and OpenAPI Generator for mobile clients, both reading from the same spec. This is a perfectly valid pattern as long as you keep the spec as the single source of truth and automate both generation steps. The spec file should live in its own repo or at the root of your backend repo, versioned and validated on every commit.

For teams evaluating their broader API architecture, understanding the tradeoffs between GraphQL and REST can also inform which generator makes sense. REST-first teams get the most value from these OpenAPI generators, while GraphQL teams have their own generation ecosystem (graphql-codegen, Relay compiler) that solves similar problems differently.

If you are building a new product and want expert guidance on choosing the right API architecture and tooling for your stack, we help teams make these decisions every week. Book a free strategy call and we will walk through your specific requirements, timeline, and budget to find the right fit.