Frequently asked questions

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.

Where Kizuna is headed:

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

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.

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.

An inferred client has to import your server’s types. That ties both to one TypeScript project, and on a large API it is what makes the editor crawl.

A generated client is a plain file. It imports @kizunajs/fetch and nothing else, works in any repository, and every API change shows up in the pull request as a diff to the client you can review.

The step itself costs nothing anymore. Agents write most of the code these days, and one line in AGENTS.md has them run kizuna generate after every route change. kizuna generate --check in CI catches the times one forgets.

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

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 routes 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.

A generator types your client against the OpenAPI document, and nothing types the document against your server. Kizuna closes that gap: the routes that answer the request generate the document and every client.

The gap hurts most on iOS. With Swift OpenAPI Generator:

• every response unwraps through .ok, .body and .json, and every type is Components.Schemas.User
• a new enum value from the server fails the whole response in apps already shipped, and the request to fix it was closed as not planned
• it runs as a build plugin, with three packages to add

Kizuna’s Swift client is one file with no dependencies. A call returns its body, a model is API.User, enums can take an unknown case, and a pull request that would break a shipped app fails.

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.

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.