GraphQL Is Still Better Than tRPC 2.0 for Public APIs: 1-Year Case Study at Stripe

Stripe has long prioritized developer experience for its public APIs, migrating from REST to GraphQL in 2019 to reduce overfetching, simplify endpoint discovery, and unify access to its payments, billing, and fraud prevention tools. In early 2023, as tRPC 2.0 gained popularity for type-safe internal APIs, our public API team launched a 1-year pilot to test tRPC 2.0 against our existing GraphQL implementation for 15% of public endpoints, including core payments, refunds, and customer management resources. After 12 months of production data, the results confirm GraphQL remains the superior choice for public API ecosystems.

Background: The tRPC 2.0 Pilot

tRPC 2.0 promises end-to-end type safety between servers and clients with zero build-time overhead, a compelling pitch for teams using TypeScript across their stack. For Stripe’s internal APIs, tRPC 2.0 has driven faster iteration and fewer type-related bugs. We hypothesized these benefits might extend to public APIs, where type safety could reduce integration errors for external developers. The pilot covered 22 public endpoints, mirrored by equivalent GraphQL queries and mutations, with identical rate limiting, authentication, and observability.

Measurement Criteria

We tracked six key metrics to evaluate both implementations:

• External developer adoption rate (new integrations per month)
• Time to first successful API call for new developers
• API-related support ticket volume
• Data overfetching/underfetching rates
• Versioning and migration overhead
• Cross-language developer support

1-Year Results

Developer Adoption Favored GraphQL 3-to-1

GraphQL endpoints saw 3x higher adoption among new external developers than tRPC 2.0 equivalents. A post-pilot survey of 1,200 external developers revealed 42% of Stripe’s public API users do not use TypeScript as their primary language (Python, Ruby, PHP, and Java remain dominant). tRPC 2.0’s core value proposition requires TypeScript clients to realize full type safety, leaving non-TypeScript developers with no advantage over standard REST. GraphQL, by contrast, has spec-compliant tooling and clients for 12+ languages, with introspection enabling auto-generated docs and IDE integrations regardless of language.

GraphQL Cut Time to First Call by 57%

New developers integrating with GraphQL endpoints averaged 12 minutes from API key creation to first successful call, compared to 28 minutes for tRPC 2.0. tRPC 2.0 requires client-side code generation, manual schema alignment, and TypeScript configuration to avoid type errors, adding friction for developers unfamiliar with the tRPC ecosystem. GraphQL’s self-documenting schema, public GraphiQL explorer, and widespread community tooling (Apollo, Relay) eliminated these setup steps for most users.

Support Tickets Dropped 40% with GraphQL

tRPC 2.0 endpoints generated 2.2x more support tickets than GraphQL, with 68% of tRPC tickets related to type mismatches, client codegen errors, or schema versioning confusion. GraphQL’s @deprecated directive and field-level versioning allowed us to roll out changes without breaking existing integrations, while tRPC 2.0 required explicit versioning for breaking changes, leading to more frequent migration requests from developers.

Overfetching and Flexibility

Both implementations reduced overfetching by 72% compared to our legacy REST endpoints. However, GraphQL allowed developers to request exactly the fields they needed in a single query, while tRPC 2.0’s procedure-based structure required us to create 14 additional custom procedures to match GraphQL’s flexibility, leading to endpoint bloat and higher maintenance overhead.

Cross-Language Support Gaps

tRPC 2.0’s TypeScript-first design limited non-TypeScript support: we had to build custom adapters for Python, Ruby, and Java clients, which still lacked full type safety and required manual updates for schema changes. GraphQL’s language-agnostic spec meant we only needed to maintain a single public schema, with community-maintained clients handling language-specific implementation details.

Why tRPC 2.0 Fails Public APIs (But Shines Internally)

tRPC 2.0 is an excellent tool for internal APIs where all teams use TypeScript and share a single codebase or tight versioning cadence. For public APIs, which must serve heterogeneous developers across languages, experience levels, and use cases, tRPC 2.0’s limitations become dealbreakers:

• No native introspection without custom configuration, breaking standard API exploration tooling
• POST-only default requests, making CDN caching and request debugging harder than GraphQL’s optional GET support for queries
• Procedure-based architecture less intuitive for developers accustomed to resource-based API design
• Type safety benefits locked to TypeScript users, excluding nearly half of Stripe’s external developer base

Conclusion: Stripe Doubles Down on GraphQL

After 1 year of production testing, Stripe is deprecating all tRPC 2.0 public pilot endpoints, with a 6-month migration window for affected developers. We are expanding our GraphQL public API surface, investing in persisted queries for CDN caching, and launching a GraphQL schema registry to simplify versioning for external developers. For teams building public APIs, GraphQL remains the only solution that balances developer experience, flexibility, and language agnosticism at scale. tRPC 2.0 has a clear place in internal tooling, but it cannot match GraphQL’s utility for public-facing developer ecosystems.