Why Kizuna?

One config, a fully typed stack.

Describe your API once. Kizuna serves it as a typed REST API, an OpenAPI document and an MCP endpoint, and generates the TypeScript, Swift and Kotlin clients that call it. No copying types between repos, no docs to keep up to date by hand.

Change the API and your editor shows you everything that breaks. Deprecate a field and every caller sees it before it’s gone. Frontend, backend, and mobile all come from one source, so a client cannot quietly drift from the server.

Agents work well against it. A route declares what it takes and what it answers, so an agent writing a caller reads the same source your compiler checks it against.

And it’s real HTTP underneath: proper REST routes, correct status codes, RFC 9457 errors. More on the about page.

What's on the roadmap?

Where Kizuna is headed:

• OpenAPI 3.2.0 output
• A TanStack Start adapter
• Whatever the future brings

Why Zod only?

Kizuna won’t support Standard Schema or other validators. It leans on Zod features directly for its inference and coercion, and committing to one validator is what keeps the types this precise.

Can I use my API from non-TypeScript clients?

Yes. Kizuna describes a real REST API, so anything that speaks HTTP can call it. The same routes generate native Swift and Kotlin clients, and are served as an OpenAPI document and an MCP endpoint.

Coming from ts-rest?

Kizuna is inspired by ts-rest and keeps the public API familiar. The migration guide maps each API to its Kizuna equivalent.

Why not just use tRPC?

tRPC is a great choice for a pure TypeScript stack, and Kizuna does not ask you to give up the RPC-like client. You still call your endpoints like functions and get fully typed results back:

import { createClient } from './api-client.generated';const client = createClient({    baseUrl: 'https://api.example.com',});const result = await client.users.

Kizuna fits better when your API has consumers outside that client: another language, a public integration, or anything reading the OpenAPI spec. The same routes also generate native Swift and Kotlin clients, so your iOS and Android apps are typed against the API too.

How can I help?

We’d love your help. Bug reports, small reproductions, and doc fixes are always welcome, and an issue or a PR for any of those is a great place to start.

Anything we merge into the core, we maintain, so we keep it to the packages we actually use. Whether an adapter or client goes first-party comes down to adoption, not age: if a framework picks up real usage, we will very likely add it. What we will not take on is a framework a handful of people use. The adapter, plugin, client, and generator APIs are all public, so you can build and publish exactly what you need today: see the extend guides.

For anything beyond a bug fix or docs, like a new feature or an API change, open an issue first so we can check it fits before you build it.

Do you offer support?

Kizuna is open source and provided as-is. Most answers are in the docs or the source. For anything else, open an issue on GitHub.

It is actively maintained alongside the products we ship on it, so issues get read. One with a small reproduction is the quickest to act on.