tRPC vs REST vs GraphQL for B2B SaaS APIs in 2026

Wednesday afternoon, a prospective client asked me a version of the same question I now hear on almost every discovery call: tRPC, REST, or GraphQL, and which one is "right" for a B2B SaaS API. There isn't a right one. There's a right one for what that specific endpoint has to do, and most SaaS products end up needing more than one answer at the same time.

What Actually Changes When You Pick tRPC, REST, or GraphQL?

The real difference is who's allowed to call the API, not which one is technically superior. tRPC assumes the caller shares your TypeScript types. REST assumes it doesn't. GraphQL assumes the caller's data needs are unpredictable enough that a fixed shape would be wasteful.

Performance, tooling, learning curve — every other comparison people argue about is downstream of that one fact. You've probably felt this already if you've ever tried to bolt a public API onto a codebase built entirely around one of these three. It usually goes badly, and it's rarely the framework's fault.

Here's the shape of the trade-off across the dimensions that actually bite in production, not the ones that show up in a comparison listicle:

| Dimension | tRPC | REST | GraphQL | |---|---|---|---| | Type safety | Full, inferred, zero codegen | None built-in; needs OpenAPI + generated types | Schema-typed, but resolver-level bugs still happen | | Who can call it | TypeScript clients sharing your repo/monorepo only | Anyone — curl, mobile, another company | Anyone with a GraphQL client | | Best fit | Internal dashboard and admin traffic | Public/partner APIs, webhooks, OAuth callbacks | Aggregating 2+ backends for one variable client | | Caching | Relies on your data layer (React Query, etc.) | HTTP caching is free and well understood | Needs its own layer — persisted queries, DataLoader | | Versioning story | Tied to your deploy; no separate contract | Decades of prior art (URL/header versioning) | Schema evolution, deprecation directives |

Nothing in that table is a tiebreaker on its own. It's a checklist for which row matters most for the specific endpoint you're about to build, not the product as a whole.

tRPC Is a Type-Safety Tool, Not an API Standard

tRPC's own documentation is blunt about what it's for: eliminating the drift between client and server type contracts in full-stack TypeScript projects, with no schema and no code generation step. That's the entire pitch. Not interoperability. Not a wire format other languages can consume. Type safety, inside one repo, inside one language.

Which means the moment a partner asks for API access in Python, or your mobile team ships in Kotlin, tRPC stops being an option for that surface — not because it's broken, but because it was never built to leave the TypeScript boundary. SD Times' 2026 comparison says this plainly: tRPC is "not suitable for public APIs." I'd go further. Treating tRPC as a stepping stone toward a public API is how teams end up rebuilding the same endpoints twice, once for internal speed and once for external reality.

None of this makes tRPC weak. On a Next.js dashboard talking to its own backend, it removes an entire category of bugs — the ones where the frontend and backend quietly disagree about a field's shape and nobody notices until production. It's just a tool with a fence around it, and the fence is TypeScript.

Where REST Still Wins: Anything a Partner Has to Call

The standalone answer: REST wins wherever a partner, a webhook, or a client outside your control needs a stable, documented contract that doesn't assume shared code. Bindbee's B2B integration guide frames partner APIs around explicit onboarding, dedicated rate limits, and a shared SLA — none of which care what language your internal app is written in.

Here's what a REST API actually gives you that the other two don't by default:

1. A partner's engineer can read your OpenAPI spec and generate a client without asking you anything.
2. Rate limiting, versioning, and caching all have twenty years of prior art you can copy instead of invent.
3. If the relationship ends, the partner's integration doesn't depend on you keeping a shared type package published forever.

If you're unclear on what a REST API actually is at the wire level versus what people mean when they say "RPC-style," it's worth getting that distinction straight before you pick — the two get conflated constantly, and tRPC is RPC-style, not REST, no matter how many people call it "our REST API" in a standup.

Is GraphQL Overkill for Your B2B SaaS?

Usually, yes — unless you're aggregating data from more than one backend for a genuinely variable set of clients. GraphQL's real job in 2026 isn't replacing REST at the edge. It's sitting on top of REST or gRPC services as an aggregation layer, letting a dashboard or a partner integration ask for exactly the fields it needs across services that were never designed to talk to each other directly.

If your B2B SaaS has one database, one primary app, and a handful of partner webhooks, you don't have the fan-out problem GraphQL solves. You have a straightforward CRUD surface. Reaching for what GraphQL actually optimizes for, which is client-driven queries across heterogeneous sources, adds a resolver layer, an N+1 query risk, and a caching story you now have to build yourself — all to solve overfetching you could have fixed with a couple of well-designed REST endpoints.

Actually — that's too clean a rule. If you're already running microservices and your admin panel genuinely needs data from four of them in one screen, GraphQL earns its keep fast. The mistake isn't choosing GraphQL. It's choosing it before you have more than one backend for it to aggregate.

What Happens When a Partner Demands GraphQL Anyway?

You don't rebuild your API around one partner's preference — you wrap the existing one behind a thin GraphQL facade instead. It happens more than people admit: an enterprise partner's integration team has standardized on GraphQL internally, and they ask if you can expose one.

The partner gets the query shape they've already tooled around; your core API stays exactly as boring and stable as it was before the request came in. This is the same pattern behind most "GraphQL APIs" you'll find on large platforms: a translation layer sitting in front of services that were never rewritten to speak GraphQL natively.

Say yes to the partner. Just don't let "yes" mean rearchitecting your entire data layer around one client's tooling preference. One demanding partner is a wrapper. Ten of them asking for the same thing is a signal your public API needs a GraphQL layer as a first-class citizen, not a favor.

The Migration Case Nobody Wants to Talk About

Numbers, for once, instead of vibes. One team's migration from Apollo Federation to tRPC took production bugs from 88 a month down to 7, cut P95 latency from 85ms to 28ms, and held 99.97% uptime across 2.4 million daily requests — according to a first-person account published on InfoQ in April 2026. That's not evidence GraphQL is bad. It's evidence federation was the wrong tool for that team's traffic.

The Hybrid Pattern I'd Actually Ship

For a B2B SaaS building on a Next.js and Prisma stack on Postgres, here's the split that holds up across most of the projects I scope:

1. tRPC for everything behind login. Every authenticated dashboard call, every internal mutation, every admin action — full type safety, zero schema maintenance, and nobody's fault when the frontend breaks because the backend changed a field name.
2. REST for anything outside your TypeScript boundary. Stripe webhooks, OAuth callbacks, health checks, and any endpoint a partner or a mobile client written in a different stack needs to call.
3. A thin, versioned REST subset for partner access, generated from an OpenAPI contract you write deliberately rather than one you reverse-engineer from tRPC procedures after the fact.
4. GraphQL only once you have a real aggregation problem — multiple services, one client, genuinely variable query shapes. Not before.

You don't start with all four. You start with tRPC and REST, and you add GraphQL the day someone actually needs it, not the day someone reads a blog post about it. If you're still deciding the rest of your stack alongside this, the SaaS MVP stack decision tree is where I'd start before locking in an API layer you'll be stuck defending in six months.

None of my current projects run a federated GraphQL layer, for what it's worth. Callidus talks to Firestore directly through security rules rather than any of these three patterns, which is its own lesson: sometimes the right answer to "REST, GraphQL, or tRPC" is none of the above, because your database's own client library already does the job.

What would you actually lose if you ripped GraphQL out of your stack tomorrow and replaced it with two REST endpoints? For most B2B SaaS products, the honest answer is: less than the GraphQL setup cost you to build in the first place.