# Hey API: a monorepo whose readme tells you to look at other repositories

> An MIT monorepo that turns OpenAPI specifications into SDKs, Zod schemas and TanStack Query hooks, with a TypeScript generator, a Python generator and sixteen example client projects. The page points at separate repositories that do not exist, its sponsor tables carry a stray closing tag, and its readme is machine synced so hand edits get overwritten.

**hey-api/hey-api** — 👨‍🚀 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.

- Repository: https://github.com/hey-api/hey-api
- Website: https://heyapi.dev
- Stars: 5,471 · Forks: 443
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/hey-api-hey-api

## The About section points at repositories that are directories

Here is the contradiction the front page cannot resolve. The About section says this is the monorepo containing all open source Hey API packages, then immediately says that for package specific documentation and quick start guides you should see the individual repositories below. There are no individual repositories below. The packages table that follows links to packages/openapi-ts and packages/openapi-python, which are directories inside this repository, and the libraries table links to packages/spec-types, also a directory here.

So the page describes a monorepo and then tells you to leave it, in the same paragraph. Nothing breaks because of it, since the relative links resolve correctly and land you on the package sources. What it does cost is a reader's trust in the next sentence, and a newcomer who follows the instruction literally will go looking for three separate codebases that do not exist.

It also hints at something real about the project's shape. Package specific guides are kept per package rather than centralised, which is the usual reason a monorepo gets described that way in the first place.

## Sixteen example projects, and the client list only names seven of them

The highlights section promises HTTP clients for the Fetch API, Axios, Angular, Next.js, Nuxt, HTTPX and more. The examples directory holds sixteen projects, and the extra names are where the real coverage is: openapi-ts-ky, openapi-ts-ofetch, openapi-ts-fastify, openapi-ts-nestjs, openapi-ts-openai, openapi-ts-pinia-colada, openapi-ts-angular-common, plus four separate TanStack Query examples for Angular, React, Svelte and Vue, one of them marked experimental.

Two details in that list are worth pausing on. There is a dedicated OpenAI example, which means the generator is being pointed at somebody else's API surface as a test case. And the TanStack Angular Query example is labelled experimental in its directory name, so it is a known moving part rather than a settled promise.

HTTPX is the odd one out in the other direction. It is on the client list but has no example directory, which fits, since HTTPX is the Python client and this generator is the TypeScript one.

## The readme is machine synced, which means your edits get overwritten

The front page is not written by hand. It is wrapped in template markers, with template-contributing-start and template-contributing-end around the contributing section, template-sponsors-start and template-sponsors-end around the sponsor tiers, and a template-license-start pair around the licence. The package scripts include a command called readme:sync that runs a TypeScript script to regenerate it, and a build pipeline orchestrated by turbo.

That is a sensible arrangement for a page that is published into six places at once, a root readme, package readmes, a website and so on. It also means the text you are reading is a build artifact. A pull request that edits the licence paragraph or the contributing paragraph by hand will conflict with the template on the next sync.

So the useful contribution is the template, not the page, which is exactly what the contributing section implies when it sends you to a guide and asks you to release a feature.

## A gold sponsor table with a closing tag that closes nothing

The sponsor section is generated too, and the generated output has a small structural fault in the first tier. The Gold block opens a table, then a tbody, then goes straight to a td at fifty percent width with no tr around it. Nine lines later it emits a closing tr. The Silver and Bronze blocks beneath it both wrap their cells in tr elements correctly.

So the one tier that contains a single sponsor is the one that lost its row wrapper. Renderers are forgiving about this, which is why nobody noticed, and the page still displays. It matters to anyone who copies the sponsor block as a template, since the pattern that is broken is the one you would copy when adding a second gold sponsor.

The tiers themselves are short. Gold is one entry, described as an open source coding agent, at opencode.ai. Silver has two, fastapi.tiangolo.com and getunblocked.com. Bronze has two more, whose logos are the only part of the page stored as webp rather than svg.

## One monorepo, two toolchains, and a Python tree pinned to 3.9

The build is TypeScript first. The root manifest is private, versioned 0.1.0, marked as the public Hey API monorepo, and typed as an ES module. Build and test run through turbo and vitest, packages are declared in a pnpm workspace, and hooks come from husky with lint-staged on top. There is a .heyapi.json at the root, so the project generates code with itself, and a .nvmrc against a stated floor of any Node.js 22 environment.

Underneath that sits a second toolchain:

```toml
[project]
name = "hey-api-dev"
version = "0.0.0"
requires-python = ">=3.9"
dependencies = ["hatchling>=1.27.0", "wheel>=0.47.0"]

[dependency-groups]
dev = ["httpx>=0.27", "mypy>=1.15", "pydantic>=2.0", "ruff>=0.11"]
```

A development project, not a published one, with ruff and mypy both configured for python_version 3.9 and ruff set to a line length of 120 with rules E, F, W and I. Its lock file is uv.lock, and the package scripts reach into it directly, for instance the format and lint targets that run ruff over the Python generator's snapshot directory after oxfmt has handled the rest.

## Formatting moved to oxfmt and oxlint, and a prettier ignore stayed behind

The lint and format scripts are now oxfmt and oxlint. The format target runs oxfmt over the repository, lint runs oxfmt in check mode followed by oxlint, and there are lint:fix and lint:fix:next variants, where the next variants add the ruff pass over the Python snapshots. Configuration for the new tools sits in .oxfmtrc.json and .oxlintrc.json.

At the root there is still a .prettierignore and no prettier configuration file to go with it. So the repository carries an ignore list for a formatter it no longer uses. That is the ordinary residue of a toolchain migration, and it is harmless in practice, since nothing invokes prettier any more.

It is worth mentioning because a stray ignore file is exactly the kind of thing that gets read as intent by a new contributor, who then assumes some part of the repository is still prettier formatted and wonders why the format script never touches it. Everything now goes through oxfmt.

## Two changelog mechanisms for one release history

There is a .changeset directory, which is the conventional home for pending release notes, and there is also a CHANGELOG.md at the root plus a whole family of scripts for producing releases: changelog:assemble, changelog:release:name, changelog:release:notes and changelog:release:tag, each running a TypeScript file under scripts/changelog. The test script targets the same area with vitest, running the files in __tests__.

So release notes are assembled and tested by code the project wrote itself, on top of a changeset workflow. That is more machinery than most projects need, and it is not without a reason: the published releases are named after dates, 2026-06-22, 2026-06-08 and a patch named 2026-06-01.2, so a date based version line needs a generator that can allocate the suffix for a second release on the same day.

The other half of that machinery is the release directory. There is a .release folder at the root alongside .vercelignore and vercel.json, which is the website side of the operation.

## The credibility claims are a CEO quote and a sponsor logo

The page opens with a pull quote, OpenAPI codegen that just works, attributed to Guillermo Rauch, CEO of Vercel, and the repository description adds that it is used by Vercel, OpenCode, PayPal, AWS and Autodesk, with millions of weekly npm downloads and 20+ plugins. The About section widens that to thousands of companies, from YC startups to Fortune 500 enterprises.

None of those numbers is verifiable from the repository, and none of the named companies links to a usage story. The one concrete endorsement on the page is structural rather than textual: the gold sponsor is the open source coding agent, whose own link goes through a redirect domain, as do both silver sponsors and both bronze ones. Sponsorship bought the placement, which is a normal thing and not a claim about adoption.

What the repository does let you check is the release cadence and the package surface. Three releases in June 2026, two generators, one types package and sixteen example projects. That is the part worth judging.

## Conclusion

Hey API is a serious code generator with an unusually broad client matrix, and its example projects are the fastest way to judge it, since sixteen directories show the generator working against fetch, axios, Angular, Next.js, Nuxt, ky, ofetch, Fastify, NestJS and four TanStack Query adapters. Three things to check first. It is a monorepo, so the generators live under packages/ and the per package guides are the ones to follow, not the root page. Its tooling spans two ecosystems, a pnpm and turbo build in TypeScript and a uv managed Python tree with ruff and mypy pinned to 3.9, so your CI needs both if you want to run everything the maintainers run. And its readme is generated from templates, so any correction you want to make upstream goes through the sync script and the contributing guide rather than a pull request that edits prose directly.

## FAQ

### What is Hey API?

It is an MIT licensed ecosystem for turning API specifications into production ready code, published as a monorepo containing all of its open source packages. The repository ships a TypeScript generator with 20+ plugins for SDKs, Zod schemas and TanStack Query hooks, a Python generator for SDKs and Pydantic models, and a spec-types package of OpenAPI and JSON Schema definitions.

### how to use @hey-api/openapi-ts

The TypeScript generator is the openapi-ts package inside the monorepo, published on npm under @hey-api/openapi-ts. The root readme points at the manual at heyapi.dev/docs/openapi/typescript/get-started, and the examples folder carries sixteen runnable projects such as openapi-ts-fetch, openapi-ts-axios and openapi-ts-next.

### Does Hey API generate Python as well as TypeScript?

Yes. The openapi-python package is a Python code generator for SDKs and Pydantic models, published on npm as @hey-api/openapi-python. The monorepo's own tooling is Python too, with a development project configured for Python 3.9 or higher using ruff and mypy.

### Do I have to use a specific HTTP client with Hey API?

No. The highlights name HTTP clients for the Fetch API, Axios, Angular, Next.js, Nuxt and HTTPX, and the examples directory goes further with ky, ofetch, Fastify, NestJS, an OpenAI example and four TanStack Query variants for Angular, React, Svelte and Vue.

### Why does the Hey API readme point me to other repositories when this is the monorepo?

The About section does say the monorepo holds all open source packages and then says to see the individual repositories below, but the package table links to directories inside this repository, packages/openapi-ts, packages/openapi-python and packages/spec-types. No separate repositories are listed.

## Sources

- [hey-api/hey-api on GitHub](https://github.com/hey-api/hey-api)
- [License: MIT](https://github.com/hey-api/hey-api/blob/main/LICENSE)
- [Project website](https://heyapi.dev)
- [README](https://github.com/hey-api/hey-api/blob/main/README.md)
- [Releases](https://github.com/hey-api/hey-api/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hey-api-hey-api