# Hey API and Voxgig, compared

> The TypeScript ecosystem's generator, with a Python generator in early development. MIT, millions of weekly npm downloads, and a plugin architecture that generates exactly what you ask for: types, a client, Zod schemas, TanStack Query hooks. TypeScript today, with a Python generator in initial development. On TypeScript specifically it is the more specialized tool. Published by Voxgig, which makes one of the two tools. Facts checked 28 September 2026.

## What it is

`@hey-api/openapi-ts` is an MIT-licensed OpenAPI to TypeScript generator with millions of weekly npm downloads, used by Vercel, OpenCode, PayPal, AWS, and Autodesk among others. TypeScript is the language it ships for. A second generator, `@hey-api/openapi-python`, for Python SDKs and Pydantic models, was at version 0.0.24 on the checked date; its README calls it initial development and the site lists Python as coming soon.

Its architecture is a plugin pipeline. You choose what gets generated: types alone, or types plus an SDK, plus Zod schemas, plus TanStack Query hooks, plus whatever else the twenty or so plugins cover. Clients are available for fetch, axios, Angular, Next, and Nuxt.

It is funded by sponsorship, with a Hey API Platform in beta. Pricing for the platform has not been announced, and the project says there will always be a free plan. The generator itself is free and open source.

## Facts

- Made by: Hey API
- License: MIT
- Source: `github.com/hey-api/hey-api` (https://github.com/hey-api/hey-api)
- Cost: Free. Platform in beta
- Language targets: TypeScript. Python in initial development

## What Hey API does that Voxgig does not

### A plugin architecture at a genuinely useful grain

Nothing else in this comparison lets you choose the output at this resolution. Generate only types for a project that already has a client. Add a fetch client for one that does not. Add Zod validators where you take untrusted input, and TanStack Query hooks where you render it. Every other tool here, Voxgig included, generates a library shaped the way the generator thinks a library should be shaped.

### Generated TanStack Query hooks

This is the standout, and it is the clearest example of what specializing in one language buys you. For a React application talking to your API, generated query and mutation hooks with correct query keys per operation remove an entire hand-written layer that otherwise rots every time the API changes. No multi-language generator will ever ship this, because the concept does not exist in Go, and that is exactly the point.

### Zod schemas from the same description

Runtime validation and static types from one source, in the shape the TypeScript ecosystem already uses, rather than a validation approach invented by the generator. Speakeasy does this too, in its own SDKs. Hey API gives it to you as a plugin you can point anywhere. Voxgig's `validate` feature checks payloads against the model's field types without emitting a schema, so there is nothing to hand to a form library or a route handler.

### Depth instead of breadth, chosen deliberately

One generator per language means the output can follow that language's conventions exactly, instead of the shape that survives translation into seven of them. That is why the Python generator is a separate codebase rather than a new target inside the TypeScript one. A multi-language generator compromises somewhere by construction: Voxgig's TypeScript is written by a generator that also has to emit Go.

## Side by side

| | Hey API | Voxgig |
| --- | --- | --- |
| License | MIT | MIT |
| Cost | Free. Platform in beta, unpriced | Free |
| Language targets | TypeScript. Python in initial development | 23 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack |
| Frontend integration | TanStack Query hooks, Angular, Next, Nuxt clients | None. The SDK is framework neutral |
| Runtime validation | Zod schemas, as a plugin | The opt-in validate feature, against the model's own field types, with no schema library |
| Cross-cutting behavior | Per plugin and per client | 20 generated features, same options in every target |
| CLI, MCP Server, REPL | No | Yes |
| Output shape | Whatever you enable, plugin by plugin | A complete SDK, features opt-in at construction |

## One API, two SDKs

Neon publishes an SDK made with Hey API. Voxgig built one from the same definition, and both were run against a mock of that definition on the same four steps: list, load, create, and remove. Voxgig's features are in the build and stay off until a client switches them on; the rows describe them switched on. Last measured 29 September 2026.

- Hey API: [`@neon/sdk 6.1.2`](https://github.com/neondatabase/neon-pkgs/tree/main/packages/sdk). The TypeScript SDK Neon publishes on npm: a client generated with Hey API's `openapi-ts` 0.98.2, inside a hand-written wrapper.
- Voxgig: [`voxgig-sdk/neon-sdk`](https://github.com/voxgig-sdk/neon-sdk). Built on 29 September 2026 from the same definition: eight targets from one run. A repository to build from, not a published package.
- The definition: Neon's published definition, `neon.com/api_spec/release/v2.json`: OpenAPI 3.0.3, 122 paths, 179 operations, Apache-2.0 by way of Neon's SDK repository. Source: https://neon.com/api_spec/release/v2.json

### What each SDK does

| | Hey API | Voxgig |
| --- | --- | --- |
| Operations callable | 177 methods | 178 of 179. The project PATCH, which is Neon's real update, has no method |
| Mock scenario on projects | 4 of 4 steps right | 4 of 4 right |
| Retries | Two retries on 423, 429 and 503, in the hand-written wrapper | On 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After |
| Timeouts | Client-wide and per call, in the wrapper. Unbounded by default | 30 seconds per attempt by default |
| Pagination | Pages, `all()` and `for await`, in the wrapper | Page and cursor state carried between calls in `ctrl.paging`, with no iterator |
| Idempotency keys | None | Generated for every mutating call, and kept across its retries |
| Rate limits | Retry-After honored on 429, 423 and 503, in the wrapper | A client-side token bucket, and Retry-After honored on 429 |
| Logging | None | Request and response logging, with auth headers redacted |
| Offline test mode | None. A fetch option lets you inject your own | A mock transport seeded with your data, which the generated tests run on |
| Metrics | None | Per-operation counts and timings, with no OpenTelemetry |
| Cancellation | An AbortSignal per call | A signal stops `stream()` between items. Only the timeout aborts a request in flight |
| Hooks | Request, response and error interceptors, from the generated client | Custom features that hook every stage of a call |
| Errors | Typed in the wrapper: not found, auth, rate limit, API, network, abort and timeout | One error class per SDK, carrying the HTTP status and a `notFound` flag |

### What the code is

| | Hey API | Voxgig |
| --- | --- | --- |
| Package | `@neon/sdk` on npm | Not published. You build it from the repository |
| TypeScript package size | 2.42 MB in 210 files | 4.01 MB in 544 files |
| Runtime dependencies | None | None |
| Languages from this build | TypeScript | TypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server |
| Shape | Resource namespaces, such as `neon.projects`, returning `{ data, error }` or throwing, as you choose, plus the raw generated functions | 75 entities, such as `Project`, each with the list, load, create, update and remove operations the API has |
| Types | Generated types per schema, and typed parameters in the wrapper | An interface per entity, from the response schema. Create takes the response type, so a TypeScript create needs a cast |
| Tests | Not run here: the comparison used the published package | 653 generated TypeScript tests pass, as do the generated Go, Python, Ruby, Lua, and PHP suites |

The same calls in each, in TypeScript. `@neon/sdk 6.1.2`:

```ts
import { createNeonClient } from '@neon/sdk'

const neon = createNeonClient({ apiKey: process.env.NEON_API_KEY!, throwOnError: true })

const projects = await neon.projects.list().all()
const project = await neon.projects.get({ projectId: 'late-frost-12345' })
const created = await neon.projects.create({ name: 'app' })
await neon.projects.delete({ projectId: 'late-frost-12345' })
```

`voxgig-sdk/neon-sdk`:

```ts
import { NeonSDK } from '@voxgig-sdk/neon-sdk'

const client = new NeonSDK({ apikey: process.env.NEON_APIKEY })

const projects = await client.Project().list()
const project = await client.Project().load({ id: 'late-frost-12345' })
// ProjectCreateData is the response schema, so without the cast TypeScript
// asks for id, created_at and the other fields the server assigns. The SDK
// wraps the input in the { project } body Neon's create expects.
const created = await client.Project().create({ name: 'app' } as any)
await client.Project().remove({ id: 'late-frost-12345' })
```

### What building and running both found

- Neon's retries, timeouts, pagination and typed errors are in a hand-written wrapper over the Hey API client. What Hey API generated is the typed functions underneath, which the package also exports as `raw`.
- apidef read Neon's project list at `body` until 8.19.0, although Neon puts it at `body.projects` beside `pagination`, so Voxgig's list read 0 projects.
- Neon's writes answer the record beside other parts: a project create answers its `project` beside `connection_uris` and `operations`. apidef 8.22.0 reads the record through that composed response, which fixed the create and 13 more of Neon's writes ([voxgig/apidef#112](https://github.com/voxgig/apidef/issues/112)).
- Voxgig maps its project update to a transfer-request PUT, and Neon's real update, PATCH /projects/{project_id}, has no method ([voxgig/sdkgen#211](https://github.com/voxgig/sdkgen/issues/211)).
- Entities named operation, context or control collided with the SDK's own type names and broke the TypeScript build on sdkgen 4.30.2. The fix shipped in 4.30.3, so the Voxgig SDK, built on 4.32.1, has it.

The full scorecard, with the evidence for every row: https://github.com/voxgig-sdk/neon-sdk/blob/main/COMPARISON.md

## Choose Hey API when

- TypeScript is the only client you need, now and in a year. If that is true, this is probably the tool to use, and the language count is not a real argument.
- You want generated TanStack Query hooks or Zod validators. Nothing else here gives you those.
- You want to generate types only, or a client only, and keep the rest of your data layer as it is.
- You want an MIT dependency with a large user base and no account.

## Choose Voxgig when

- You need more than one language. That is the whole difference and it is a big one.
- You want retry, caching, idempotency, pagination and cost behavior that means the same thing in Go and Python as it does in TypeScript, provable from one shared test corpus.
- You need the CLI, MCP Server, Agent Skills or REPL surfaces over your API.
- You are the API provider shipping to customers whose language you do not get to choose.

## Limits of this comparison

- The language-count row compares a multi-language generator with a single-language one, and should not be read as a measure of either.
- On TypeScript output specifically, judged as TypeScript, Hey API is the more specialized tool and a React team may well be happier with it.
- The Hey API Platform is in beta and unpriced. Hey API is the source for its eventual commercial model.
- The SDK pair is one API, compared in TypeScript against a mock of its definition. Neon's SDK is a hand-written wrapper over a Hey API client, so its retries, pagination and typed errors belong to Neon's engineers, not to the generator.

Corrections go to info@voxgig.com. A correction changes the page and moves its checked date.

## First-party sources

- [heyapi.dev](https://heyapi.dev)
- [Hey API on GitHub](https://github.com/hey-api/hey-api)
- [The Python generator](https://github.com/hey-api/openapi-python)

## The other comparisons

- [All SDK generator comparisons](https://voxgig.com/sdk/comparisons): the index, the method, and the wider field.
- [OpenAPI Generator](https://voxgig.com/sdk/comparisons/openapi-generator): The community generator most APIs have shipped an SDK from at least once.
- [Speakeasy](https://voxgig.com/sdk/comparisons/speakeasy): Commercial SDK generation whose generator became AGPL-3.0 open source in September 2026.
- [Fern](https://voxgig.com/sdk/comparisons/fern): SDKs and a documentation site from one definition. Part of Postman since January 2026.
- [Stainless](https://voxgig.com/sdk/comparisons/stainless): The generator behind many of the best-known AI SDKs. Its hosted product is winding down.
- [Cloudflare Forge](https://voxgig.com/sdk/comparisons/cloudflare-forge): Cloudflare's open-source generation pipeline, published on 28 September 2026.
- [APIMatic](https://voxgig.com/sdk/comparisons/apimatic): The longest-running commercial generator here, and the only one that converts between description formats.
- [liblab](https://voxgig.com/sdk/comparisons/liblab): SDK generation shaped as a release pipeline. Part of Postman since November 2025.
- [Kiota](https://voxgig.com/sdk/comparisons/kiota): Microsoft's client generator, built so you do not need a separate SDK per API.
- [Voxgig SDK Generator](https://voxgig.com/sdk)