REST API explained: the business case behind every endpoint

In 2008, Twilio launched with a radical bet: no sales team, no enterprise contracts, no GUI. Just an API. Developers could send an SMS with five lines of code and a credit card. The product was the API. By 2016, that bet was generating $277 million in annual revenue. By 2023 – $4.15 billion [1]. That’s 1,400% growth in seven years, built entirely on endpoints that other people’s software calls.

Jeff Lawson, Twilio’s CEO, said something that should matter to every founder building software: “We don’t sell to companies. We sell to developers” [2]. The REST API wasn’t Twilio’s delivery mechanism. It was the product itself.

If you’re building a product that other systems need to talk to – and in 2026, almost every product is – then your API design isn’t a technical decision. It’s a business decision with direct revenue consequences.

What a REST API actually is – three sentences

Your app stores data and does things with it. A REST API is a set of URLs that let other software access that data and trigger those actions over the internet – the same way a browser loads a web page. Each URL represents a thing (a user, an order, a payment), and you use standard actions (GET to read, POST to create, PUT to update, DELETE to remove) to interact with it.

That’s it. REST stands for Representational State Transfer, coined by Roy Fielding in his 2000 doctoral thesis [3]. But what matters to you as a founder isn’t the academic definition – it’s what happens when your API is good, and what happens when it isn’t.

Stripe’s API converts 3x better than competitors

Stripe processes $1 trillion in payment volume annually [4]. They didn’t win on price – their fees are standard. They didn’t win on features – PayPal and Braintree had feature parity for years. They won because a developer could integrate Stripe in an afternoon and the competition took a week.

Patrick Collison, Stripe’s co-founder, obsessed over the API experience. The documentation reads like a conversation. Every endpoint has a working code sample in seven languages. The error messages tell you exactly what went wrong and how to fix it. The result: developers regularly cite Stripe as the gold standard for API documentation, and the company attributes much of its growth to developer adoption speed rather than pricing or features [5].

$1T

[4] Stripe, 2024

This isn’t a documentation problem. It’s a product design problem. When a developer evaluates your API, they’re asking: “How fast can I ship this integration?” Every confusing endpoint, every missing error message, every inconsistent naming convention adds friction. Friction kills adoption. Adoption is revenue.

Good API design is an architecture decision with direct commercial impact. We treat it that way in every product we build.

Twitter proved that API power is also API risk

In February 2023, Twitter (now X) announced the end of free API access [6]. Overnight, the price jumped from $0 to $42,000 per month for the enterprise tier. The basic tier – $100/month – was capped at 10,000 tweets. The old free tier had allowed 2 million.

The third-party ecosystem that had spent a decade building on Twitter’s API – apps like Tweetbot, Twitterrific, academic research tools, social media managers – was destroyed in weeks. Tweetbot shut down immediately. Twitterrific, which had existed since 2007, closed [7]. Entire businesses built on a single API dependency vanished because one company changed its pricing.

This is also why building your own API matters. When partners integrate with your API, the switching cost works in your favor. Expedia generates 90% of its $12.8 billion revenue through partner API integrations – hotels, airlines, and travel agents plugged into their booking system [8]. Those partners aren’t leaving. They’ve built their businesses on Expedia’s endpoints. That’s a moat no marketing budget can replicate.

The API economy: $10.9 trillion and growing

APIs stopped being a technical implementation detail years ago. They’re an economic layer.

The global API economy generated an estimated $10.9 trillion in impact in 2023, projected to reach $14.2 trillion by 2027 [9]. That number isn’t just Twilio and Stripe – it includes every company that exposes data through APIs, every integration that connects two systems, every marketplace built on partner endpoints.

The numbers at the company level are just as stark: 65% of companies now generate revenue directly through APIs, and 43% generate more than 25% of their total revenue from API-driven channels [10].

Salesforce is the clearest example. Their platform revenue – the money third-party developers pay to build on Salesforce’s APIs – exceeds what they make from their own CRM product. The platform became more valuable than the product.

If you’re planning a product where partners, resellers, or third-party developers need access to your data – and that describes most SaaS products – the API is the product. Its design determines your development cost, your time to market, and your long-term competitive position.

What bad API design actually costs

In August 2013, Amazon.com went down for 40 minutes. The estimated revenue loss: $4.8 million [11]. At Amazon’s scale, every internal service communicates through APIs. When one fails, the cascading impact across dependent services turns a local problem into a site-wide outage.

That’s the catastrophic end. The chronic end is worse because it’s invisible.

70% of developers say poorly designed APIs directly impact their productivity [12]. That’s from Postman’s 2023 State of the API report – 40,000 developers surveyed. Bad APIs don’t just slow down your partners. They slow down your own team. Every internal service that talks to another internal service uses an API. When those APIs are inconsistent, poorly documented, or fragile, your developers spend more time debugging integrations than building features.

The cost compounds. A developer who spends 30 minutes debugging a confusing API response – multiplied across 10 developers, 5 times a week, 50 weeks a year – is 1,250 hours of lost productivity. At $75/hour, that’s $93,750 a year. On one bad API.

REST vs GraphQL vs gRPC – the one-paragraph decision

Build REST unless you have a specific reason not to. REST works over standard HTTP, every developer knows it, every tool supports it, and it’s the easiest to cache. If your frontend needs to fetch deeply nested data from multiple related resources in a single request – a dashboard pulling user profiles, their orders, each order’s items, and each item’s reviews – GraphQL saves you from making 15 separate REST calls. If you’re building internal microservice communication where latency matters more than human readability, gRPC’s binary protocol is 5-10x faster than JSON over REST [13]. For everything else – public APIs, partner integrations, mobile backends, standard CRUD applications – REST is the right call.

	REST	GraphQL	gRPC
Best for	Public APIs, partner integrations, most products	Complex frontends, mobile apps with bandwidth constraints	Internal microservices, high-throughput systems
Learning curve	Low – every developer knows HTTP	Medium – new query language, schema design	High – Protocol Buffers, streaming, code generation
Caching	Built-in (HTTP caching, CDN)	Hard (POST-only by default)	Manual
Tooling	Universal	Growing but still maturing	Specialized
Our recommendation	Default choice	Only when REST creates too many round-trips	Only for internal service-to-service calls

We’ve built products with all three. For the vast majority of founders reading this, REST is the answer. The products we build use RESTful APIs with clean versioning, proper error handling, and documentation that makes integration painless. That’s the scalable foundation most products need.

What good REST API design looks like – the non-negotiables

You don’t need to understand the implementation. You need to know what to demand from whoever builds it.

Versioning from day one. Your API will change. If you don’t version it (v1, v2), every change breaks every integration. Stripe has maintained backward compatibility across years of changes because they version aggressively.

Consistent naming and structure. /users/123/orders should behave identically to /products/456/reviews. Same patterns, same error formats, same pagination. Developers learn one endpoint and understand them all.

Useful error messages. “400 Bad Request” tells a developer nothing. “The ‘email’ field must be a valid email address. You sent ‘not-an-email’” tells them exactly how to fix it. Stripe’s error messages include a link to the relevant documentation page. That’s why their integration time is half the industry average.

Rate limiting and authentication. Without rate limits, one misbehaving partner can take down your entire system. Without proper authentication (OAuth 2.0 or API keys with scoping), you can’t track usage, bill partners, or revoke access when needed.

Documentation that works. Not a PDF. Not a wiki that’s six months out of date. Interactive documentation with working examples, generated directly from your API code so it’s always current. This is what converts developers into paying users, as Stripe proved.

The conversion impact of good developer experience is measurable. Stripe, Twilio, and Plaid all cite developer onboarding speed as their primary competitive metric – not features, not price.

Your product is an API

Every data point in this article leads to the same conclusion. Twilio’s $4.15 billion proves that an API can be the product. Stripe’s $1 trillion in volume proves that API design drives adoption. Twitter’s $42,000 pricing change proves that API dependency is a strategic risk. Expedia’s 90% partner revenue proves that APIs create moats. Amazon’s $4.8 million outage proves that API quality has direct financial consequences.

The founders who treat API design as an afterthought – “we’ll clean it up later” – end up with partner integrations that break, developer adoption that stalls, and technical debt that makes every new feature more expensive than the last.

The founders who treat API design as a first-class product decision end up with platforms.

---

We build APIs that become platforms – versioned, documented, and designed for the integrations you haven’t imagined yet. Tell us what you’re building and we’ll scope the API layer alongside the product.

References

[1] Twilio, Inc., “Annual Revenue: $277M (2016), $4.15B (2023),” SEC filings and annual reports. investors.twilio.com

[2] J. Lawson, “Ask Your Developer,” Harper Business, 2021.

[3] R. Fielding, “Architectural Styles and the Design of Network-based Software Architectures,” Doctoral dissertation, University of California, Irvine, 2000.

[4] Stripe, “Stripe processes over $1 trillion in total payment volume,” 2024. stripe.com/newsroom

[5] P. Collison, multiple interviews and Stripe blog posts on developer experience as competitive advantage, 2018-2024. stripe.com/blog

[6] Twitter Developer Platform, “New pricing for the Twitter API,” February 2023. developer.twitter.com

[7] The Verge, “Third-party Twitter apps are dead,” January 2023. theverge.com; Tweetbot and Twitterrific shutdown announcements, January 2023.

[8] Expedia Group, “Annual Report 2023 – partner and affiliate revenue,” SEC filing. investors.expediagroup.com

[9] Gartner, “API Economy Impact Report,” 2023. Mordor Intelligence, “API Management Market Forecast,” 2024.

[10] Postman, “2023 State of the API Report – API monetization data,” postman.com/state-of-api

[11] Amazon.com outage, August 19, 2013. Business Insider, “Amazon.com Goes Down, Loses $66,240 Per Minute,” 2013.

[12] Postman, “2023 State of the API Report – 40,000 developer survey,” postman.com/state-of-api

[13] gRPC performance benchmarks, Google Cloud documentation, 2024. cloud.google.com/blog