Why ts-kizuna?

One contract, a fully typed stack.

Describe your API once. ts-kizuna infers a typed server and a client you call like a function straight from the contract, and generates OpenAPI docs, native Swift and Kotlin clients, and an MCP server from the same definition. 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, right then. Deprecate a field and every caller sees it before it’s gone. Frontend, backend, and mobile stay in step because they all come from one source, so the bug where a client quietly drifts from the server just stops happening.

And it’s real HTTP underneath: proper REST routes, correct status codes, RFC 9457 errors.

The goal is simple: define your API once, and keep every client in sync with it. More on the about page.

Is it ready to use?

It runs in production in our own apps, so it’s battle-tested. The way you define and call your API is still settling, so ts-kizuna is in beta and moving toward a stable v2. Pin a version for production and follow the release notes when you upgrade.

Why is it already 1.0 if it’s in beta? ts-kizuna began as an internal tool. We built it for our own apps and shipped it for a long time before we open-sourced it, so by the time it became public it had already been through many versions. We kept that history rather than resetting the number, which is why a beta carries a 1.x version. The label is about the API surface still settling, not about stability.

What's on the roadmap?

We’re just getting started. Here’s where ts-kizuna is headed:

• A stable v2 syntax, with the way you define and call your API locked in
• SSE and streaming responses
• A TanStack Query client, built from the same contract
• Whatever the future brings

Why Zod only?

ts-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. ts-kizuna describes a real REST API, so anything that speaks HTTP can call it. The same contract also generates an OpenAPI document, native Swift and Kotlin clients, and an MCP server.

Coming from ts-rest?

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

Why not just use tRPC?

tRPC is a great choice for a pure TypeScript stack, and you don’t give up the RPC-like client by choosing ts-kizuna. You still call your endpoints like functions and get fully typed results back:

import { KizunaClient } from '@ts-kizuna/fetch';import { contract } from '@shared/contract';const client = new KizunaClient(contract, {    baseUrl: 'https://api.example.com',});const result = await client.users.getUser({    params: {        id: '1',    },});

The difference is that ts-kizuna is the better fit when your API also has consumers outside that client, like another language, a public integration, or anything reading the OpenAPI spec.

With ts-kizuna, you also get native Swift and Kotlin clients from that same contract, 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.

Everything we merge into the core is something we commit to maintaining for the long haul, so we don’t take additions lightly. We keep it small and stick to the packages we actually use, which is why new first-party adapters and clients won’t be merged. The better news: the adapter and client APIs are public, so you can build exactly what you need (see the extend guide).

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?

ts-kizuna is open source and provided as-is. The docs are thorough and the source is open, so most answers are within reach. For anything else, open an issue on GitHub. For production, pin a version so you control when anything changes.

Why is it called ts-kizuna?

絆 (kizuna) is Japanese for a deep, enduring bond, which is what one contract gives everything built on top of it. More on the about page.