oRPC: A TypeScript Contract Layer That Puts OpenAPI Coercion in the Middle

The Problem oRPC Solves: Contract Drift Between Server and Client

Most TypeScript API projects start with a server, then hand-write a client or generate one from OpenAPI. The server schema and the client types drift apart. oRPC attacks that by defining an API contract as the single source of truth. The @orpc/contract package holds that definition. @orpc/server implements it, and @orpc/client consumes it with full type inference. If you change a contract field, the client type updates immediately. That is the core value. It is aimed at teams building APIs where the client and server live in the same repository or at least share a TypeScript monorepo. It is less useful if your clients are not TypeScript or if you must serve many external consumers.

How the Contract Flows Through the Packages

The contract is not just a type definition. It is a runtime object that carries validation logic. You define a procedure with an input schema, an output schema, and a handler. The server package interprets that contract and exposes it over HTTP. The client package creates a typed caller from the same contract. No code generation step appears in the README; the types flow directly from the contract object. That is the key mechanism. The @orpc/openapi package adds OpenAPI compatibility, which means you can generate documentation or feed the contract into OpenAPI tooling. The @orpc/json-schema package handles what the description calls smart coercion for OpenAPI requests. That suggests it converts incoming OpenAPI request data into the types your schema expects. The design is modular: every feature is a separate npm package, from @orpc/zod to @orpc/hibernation.

Getting Started: Install the Packages You Actually Need

The README's example defines a router with os from @orpc/server, validates input with a Zod schema, and calls it from a client created with createORPCClient and an RPCLink from @orpc/client/fetch, with no code generation. @orpc/contract is for defining the API contract as a separate source of truth, and @orpc/zod, @orpc/valibot and @orpc/arktype are JSON Schema converters for those libraries. For framework support, the monorepo includes packages such as @orpc/next and @orpc/node. The @orpc/openapi package is optional unless you need OpenAPI output. The beta versions, such as v2.0.0-beta.48, are published to npm under the @orpc scope.

The Schema Library Choice: Zod, Valibot, or ArkType

oRPC does not force one validator. It has separate integration packages for Zod, Valibot, and ArkType. That is a strength if you already use one of those. It is also a maintenance burden for the project, because each integration must track upstream changes. The README lists all three as equals, so you can pick based on your existing stack. Zod is the most common, but Valibot offers a smaller footprint and ArkType focuses on performance. If you are starting fresh, the choice matters because it affects every contract you write. The monorepo also contains an @orpc/effect package for Effect users.

Where oRPC Struggles: Beta Status and Package Sprawl

The most obvious limitation is the version number. v2.0.0-beta.48 means the project is still in beta. The release dates are close together, with three releases in about eight days, which shows active development but also implies instability. If you adopt oRPC, you must budget for breaking changes. The second issue is package sprawl. The README lists over twenty packages. That gives flexibility, but it also means you must learn which packages you need and track updates across many dependencies. Packages carrying the experimental- prefix, such as @orpc/experimental-lock, are explicitly experimental. The @orpc/hibernation package depends on platform-specific APIs like Cloudflare's Hibernation WebSocket, which only work on certain runtimes. If you are on a standard Node.js server, that package is irrelevant.

Alternatives: tRPC and Plain OpenAPI Generation

The most direct alternative is tRPC, which also provides end-to-end type safety. The difference is that tRPC is tightly coupled to its own client and server, and it does not naturally produce OpenAPI documents. oRPC has a separate @orpc/openapi package that adds OpenAPI compatibility. Another alternative is to skip the framework entirely and use OpenAPI as the source of truth, generating types with tools like openapi-typescript. That approach works for any client language, but it requires a code generation step and does not give you type inference from a server implementation. oRPC usually inverts that: the TypeScript code is the source, and OpenAPI is an output, though @orpc/contract also documents generating a contract from OpenAPI.

Maintenance, Licensing, and the Cost of Upgrades

The project is MIT licensed, so you can use it commercially without paying for a license. Maintenance cost is real: with over twenty packages, every release requires updating several dependencies. The beta cadence means you should pin exact versions and review changelogs before upgrading. The @orpc/opentelemetry and @orpc/pino packages indicate the project takes observability seriously, which helps in production, but they are extra packages to maintain. You should assume that upgrading from one beta to the next may require code changes.

Editorial conclusion

Adopt oRPC if you want a single TypeScript contract that drives both server and client with end-to-end type safety, and if you are comfortable with a v2.0.0-beta release cycle. Do not adopt it if you need a stable, long-term API or if you dislike managing many small packages. Before committing, verify that the specific integrations you need (Next.js, NestJS, Cloudflare, or the schema library of your choice) are maintained and that the beta API matches your use case, since breaking changes are still possible.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes