Hey API: OpenAPI Codegen With a Plugin Layer Instead of a Template
👨🚀 Turn API specifications into production-ready SDKs, validators, mocks, and more. 20+ plugins. Millions of weekly npm downloads. Used by Vercel, OpenCode, PayPal, AWS, Autodesk, and many more.
At a glance
- What is it?
- Hey API turns OpenAPI and JSON Schema documents into TypeScript SDKs, Zod validators, TanStack Query hooks and Python clients. The monorepo splits a TypeScript generator, a Python generator and a shared spec-types package, and the plugin list is the real surface area you are adopting.
- Who is it for?
- Adopt Hey API when your source of truth is an OpenAPI or JSON Schema document and you want generated TypeScript that compiles, with Zod schemas and TanStack Query hooks produced from the same input. Skip it if you need a language outside the TypeScript and Python generators, or if you cannot run Node.js 22 or newer in CI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Spec Drift Between the OpenAPI Document and the Client Code
An OpenAPI document describes endpoints, parameters, request bodies and responses. Application code that calls those endpoints describes the same thing again, by hand, in TypeScript interfaces and fetch wrappers. The two descriptions drift. A field gets renamed in the spec, the hand-written interface keeps the old name, and the mismatch surfaces at runtime rather than at compile time.
Hey API targets that gap. The README describes it as an ecosystem for turning API specifications into production-ready code, and the monorepo ships two generators: openapi-ts, a TypeScript code generator with 20+ plugins for SDKs, Zod schemas, TanStack Query hooks and more, and openapi-python, a Python code generator for SDKs and Pydantic models. The audience is backend and platform teams who publish a spec, plus frontend teams who consume it. If your API is described somewhere other than OpenAPI or JSON Schema, this project has nothing to work with.
What Actually Sits in the Monorepo
Three packages are named in the README. packages/openapi-ts is the TypeScript generator published to npm as @hey-api/openapi-ts. packages/openapi-python is the Python generator published as @hey-api/openapi-python, notable because it is distributed through npm even though its output is Python. packages/spec-types holds TypeScript definitions for OpenAPI and JSON Schema specifications with complete inline documentation, published as @hey-api/spec-types.
The README states the generators run in any Node.js 22+ environment and accept any OpenAPI specification. That Node floor is a real constraint: it applies to the generation step, not to the generated code, so a team on an older Node runtime in CI has to upgrade the build image before the generator will run at all. The repository is TypeScript, MIT licensed, and the default branch is main.
Plugins Are the Architecture, Not an Add-On
The design decision that separates Hey API from a template-driven generator is that output is composed from plugins rather than selected from a fixed menu of language targets. The README lists core plugins for SDKs, then names HTTP clients for Fetch API, Axios, Angular, Next.js, Nuxt and HTTPX, and separately lists Zod schemas, TanStack Query hooks and Pydantic models. The stated goal is to reduce third-party boilerplate, and customization happens through plugins.
That means a single OpenAPI document can produce a typed SDK plus runtime validators plus query hooks that share the same generated types, instead of three artifacts maintained by three tools. It also means the plugin list is the compatibility surface. If your HTTP client of choice is not among the ones named, the generator does not cover you out of the box. The README does not enumerate all 20+ plugins, so the manual at heyapi.dev is where the actual plugin inventory has to be checked before you plan around it.
Getting It Running: The Commands the Documentation Gives
The README points to per-package quick start guides rather than inlining install steps, so the concrete entry points are the manual pages: heyapi.dev/docs/openapi/typescript/get-started for the TypeScript generator and heyapi.dev/docs/openapi/python/get-started for the Python one. Installation is through npm, with the packages published as @hey-api/openapi-ts, @hey-api/openapi-python and @hey-api/spec-types.
What the README does confirm is the runtime requirement (Node.js 22+) and the input contract (any OpenAPI specification). It does not show a config file, a CLI invocation or a plugin registration snippet. Anyone evaluating this should read the get-started page for the target language before assuming a config shape, because the plugin model means configuration is where most of the setup work lives. Treat the README as a package index and the manual as the actual installation documentation.
Where the Generator Is the Wrong Tool
The generator's input is a specification, so it inherits every weakness of that specification. A spec with loose schemas, missing response definitions or free-form objects produces loose types. The README claims production-grade code that compiles, which is a claim about compilation, not about how precisely the generated types match your server's real behaviour. If the spec is wrong, the generated client is wrong in the same way and it compiles anyway.
Language coverage is the harder boundary. Only TypeScript and Python generators are listed. A Go, Java, Rust or C# service cannot use this monorepo, regardless of how good the TypeScript output is. There is also a versioning exposure: the repository shows releases on 2026-06-01, 2026-06-08 and 2026-06-22, roughly a one to three week cadence. Generated code is checked into your repository in most workflows, so a generator upgrade can produce a large diff. Nothing in the supplied material describes a stability guarantee or a long-term support line, so pinning the version is the only control the material supports.
How This Differs From openapi-generator
openapi-generator is the obvious comparison: it is a Java-based tool with a large catalogue of language targets, driven by Mustache templates that you can fork and edit. Hey API takes the opposite route. It covers two languages and exposes extension through a plugin API inside the tool rather than through template files you copy into your repository.
The practical difference is where customization lives. With a template-based generator, a custom change means maintaining a fork of the template and re-applying it as upstream templates move. With Hey API, the README frames customization as plugins, which keeps the extension inside the tool's own model. That is a better fit if you are generating TypeScript for a frontend and want Zod or TanStack Query output from the same run. openapi-generator remains the option when the target language is not TypeScript or Python, or when you need a template escape hatch that a plugin API does not provide. The README's own positioning, quoting Guillermo Rauch of Vercel, is narrow: OpenAPI codegen that just works.
Licence, Maintenance and the Cost of Staying Current
The repository is MIT licensed, which permits commercial use and modification of the generator itself. That covers the tool. It does not automatically settle the licence status of the OpenAPI documents you feed it, and it says nothing about the generated output's provenance if your spec was derived from someone else's API. Those are questions for your own legal review, not something the README answers.
The maintenance cost is the release cadence. With pushes to main as recent as 2026-08-24 and tagged releases every one to three weeks through June 2026, a team that pins the generator will accumulate upgrade work, and a team that floats the version will see generated diffs appear without warning. Either way the generated files are a build artifact that reviewers have to read. Budget for that, and decide deliberately whether generated code is committed or produced during the build. The README gives no guidance on that choice, and the answer depends on whether your CI can run Node.js 22+ at build time.
Who Should Adopt It, and What to Check First
The fit is a team whose API is already described in OpenAPI or JSON Schema, whose consumers are TypeScript or Python, and whose CI can run Node.js 22 or newer. The plugin model pays off when you want the SDK, the validators and the query hooks generated together rather than assembled from separate tools.
The misfit is a polyglot backend that needs clients in four languages, or a team stuck on an older Node runtime, or a project whose spec is too loose to generate meaningful types. In those cases the generator will run and produce something, and the something will not be worth the diff.
Before adopting, verify three things from the manual rather than the README: the full plugin list at heyapi.dev, whether your HTTP client appears among Fetch API, Axios, Angular, Next.js, Nuxt and HTTPX, and the exact configuration keys for the get-started page of your target language. The README does not contain them.
Editorial conclusion
Adopt Hey API when your source of truth is an OpenAPI or JSON Schema document and you want generated TypeScript that compiles, with Zod schemas and TanStack Query hooks produced from the same input. Skip it if you need a language outside the TypeScript and Python generators, or if you cannot run Node.js 22 or newer in CI. Before committing, verify the exact plugin set against the manual at heyapi.dev, confirm your HTTP client (Fetch, Axios, Angular, Next.js, Nuxt, HTTPX) is listed, and pin the generator version, because the release cadence shown in the repository is roughly every one to three weeks and generated output changes with it.
Community notes