On June 30, 2023, Apollo, one of the most popular third-party Reddit apps on the iPhone, shut down for good. Nothing was wrong with the app. Its developer, Christian Selig, had done the arithmetic on Reddit’s new API pricing: $12,000 per 50 million requests, against roughly 7 billion requests a month, came to about $1.7 million a month, or $20 million a year. Apollo charged its users $12.99 a year.
The usual reading of that story is about Reddit’s greed or Apollo’s dependency. The more useful reading, if you are a product manager, is that Reddit spent years making a promise it never wrote down, and then discovered what it cost to take that promise back. Every company that opens an API is making the same kind of promise. Most decide to do it in a sprint planning meeting.
An API platform strategy is not a technical decision about endpoints and authentication. It is a decision about what you are willing to commit to, for how long, and to whom, before you know what anyone will build on top of it.
An API Makes Three Promises, Not One
When a team says “let’s open up an API,” they usually mean one thing: let outside developers read and write our data. The people who build on it hear three things.
A promise of access. You will let me in, and you will keep letting me in. This is the promise that feels cheapest at launch, because at launch nobody is using it.
A promise of stability. What works today will work tomorrow. Field names, response shapes, rate limits and error codes will not shift under me without warning.
A promise of economics. The terms I build my business on (free, cheap, or priced in a way I can plan around) will stay roughly where they are long enough for my investment to pay back.
You can change any of these. What you cannot do is change them for free, because by the time you want to, someone has made a bet on the old version. The cost of a broken promise lands on them first and on you second, but it always lands on you eventually: in trust, in developer goodwill, in the ecosystem that stops building, in the press cycle.
Reddit, Twitter and Slack Each Broke a Different One
The last few years produced a clean set of examples, because three large platforms each walked back a different promise.
Twitter broke the economics promise. In early 2023 it ended free API access and replaced it with paid tiers. The basic tier was $100 a month; enterprise access was reported to start at $42,000 a month for 50 million tweets, with nothing in between. Academic researchers, hobby bots and small analytics tools had built on the old terms for more than a decade. The gap between $100 and $42,000 was the entire middle of the ecosystem, and most of it simply left.
Reddit broke the economics promise too, but the access promise was the real casualty. Reddit’s CEO, Steve Huffman, said it was “a good time for us to tighten things up,” and the company said the pricing was not flexible. Apollo, RIF and Sync all closed on the same day. Large subreddits went dark in protest. Reddit’s position was defensible on its own terms (it wanted to be paid for data being used to train AI models and to move users into its own app), but the way it did it told every remaining developer that the terms could change at any time, by any amount.
Slack broke the access promise quietly. In 2025, Salesforce modified Slack’s API terms to prohibit bulk export of data, persistent copies, archives and indexes, and the use of that data in large language models. Glean, an enterprise search company whose Slack integration indexed customer messages, told its customers the change would limit access to “a query-by-query basis.” The API still existed. The thing people had built on it no longer worked.
Notice what these three have in common. None of them was a technical failure. Each was a strategy change, made years after the original decision to open the platform, by people who were not in the room for that original decision. The original API was shipped as a feature. It was unwound as a strategy.
You Are Promising More Than You Wrote Down
Product teams often comfort themselves with their terms of service. The contract says we can change the API at any time, so we have not promised anything.
Software engineer Hyrum Wright described why that comfort is false. His observation, now known as Hyrum’s Law, reads: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.”
That includes the order fields come back in, how long a request takes, which error you return on a malformed date, and the undocumented endpoint your mobile team uses that a third party found by watching network traffic. Your written promise is the floor. Your actual promise is everything anyone can observe.
I learned this inside a company rather than outside one. Running IT operations at a large telecom, I watched a provisioning interface get built as a quick integration for one internal billing team. Within a couple of years it had more than a dozen consumers, most of whom nobody had approved, several of whom depended on a field that was only populated by accident. When the owning team tried to retire it, the retirement took longer than the original build and needed a steering committee. The interface had been designed in a week. Unwinding the promise took most of a year.
Internal APIs teach the lesson cheaply. Public ones teach it in the press. The switching costs that make a product sticky for customers work in reverse on you: every integration someone builds on your platform is also a switching cost you have imposed on yourself.
Stripe Chose the Other Expensive Path
The alternative to breaking promises is keeping them, and that is not free either. Stripe is the clearest example of a company that decided, early, to pay that bill on purpose.
According to a 2017 post from Stripe’s engineering team, the company has maintained compatibility with every version of its API since its founding in 2011. It does this with date-based versions: each account is pinned to the API version that existed on its first request, and every backwards-incompatible change is written as a small module that translates new responses back into old shapes. By the time of that post, Stripe had shipped almost a hundred breaking changes over six years without forcing a single customer to rewrite their integration.
The same post is candid about the cost. Every supported version adds code that someone must understand and maintain. Without discipline, version checks spread through the codebase and make it slower and more fragile. Stripe runs an internal API review process specifically to stop that from happening.
That is a strategic choice, not an engineering one. Stripe’s product is the API. Developer trust is its distribution channel. Spending engineering capacity to never break an integration is spending on the core of the business. For most companies, the API is a side door, and they would never fund that level of compatibility. That is fine, as long as they know it before they open the door, and price and position the API accordingly.
When the Promise Pays
None of this is an argument against opening a platform. Some of the most valuable positions in software exist because a company made the promise and kept it.
Shopify is the obvious case. In 2021, its partner ecosystem (app developers, agencies, theme designers) generated $32 billion in revenue, which the company said was nearly seven times Shopify’s own revenue that year. Those partners solve problems Shopify would never prioritize on its own roadmap, and every app a merchant installs makes that merchant harder to move to a competitor. That is the platform version of a network effect: more merchants attract more developers, which attract more merchants.
The difference between Shopify and Twitter is not that one opened an API and the other did not. It is that Shopify’s business model depends on partners succeeding, so the economics promise is aligned with its own incentives. Twitter’s later business model depended on owning the user experience and the data. Once incentives diverged from the promise, the promise broke. That is the test worth running before launch, not after.
Five Questions to Answer Before You Open the Door
This is the practice. Before an API goes public (or before an internal API gets a second consumer), get the answers to these on paper, with the names of the people who agreed to them.
1. Is the API the product, a channel, or a convenience? If it is the product (Stripe, Twilio), compatibility is a core investment. If it is a channel (Shopify), partner success is part of your revenue model. If it is a convenience, say so, and keep the surface area deliberately small.
2. Which of our future strategies would this API block? Write down the two or three directions the business might plausibly take in five years. Would a rich public API compete with your own app? Would it give away data you might want to sell or use to train your own models? Reddit and Slack both hit this wall. If a plausible future strategy conflicts with the access you are about to grant, grant less now. It is far easier to open a door wider than to close it.
3. What is the deprecation policy, in numbers? “We may change this at any time” is not a policy; it is a liability you have deferred. Commit to a real window (twelve months is common for breaking changes) and a real communication path. The same rules that apply to removing a feature customers rely on apply here, with higher stakes, because the people affected are building businesses, not just habits.
4. What is the pricing path, even if launch is free? If you will ever charge, decide the shape now: per call, per seat, revenue share, tiered. Publish that it exists. A free tier with a visible paid tier above it is an economics promise developers can plan around. A free API with no stated future is the Twitter setup, waiting for a new owner. The thinking is close to deciding where to put the fence on a free tier, except the people on the free side are building on you.
5. Who owns the promise after the launch team moves on? The team that ships an API is rarely the team that has to keep it. Name an owner, give them a budget line, and put the API’s consumers on someone’s quarterly review. Orphaned APIs are how undocumented behavior turns into permanent commitments.
If you cannot answer question two, do not open the API yet. Ship a narrow integration with a few named partners under contract instead. You learn what people want to build, you keep the ability to change course, and you can widen access when the strategy is clear. This is the same logic behind treating any move that is hard to reverse as a one-way door: slow the decision down in proportion to how expensive it is to undo.
If You Already Opened It
Most product managers reading this inherited an API rather than designed one. The practice still applies, just in reverse order.
Start by finding out what you have actually promised. Pull the logs and list every consumer, every endpoint in real use and every undocumented behavior someone depends on. The list will be longer than the documentation. Then write the deprecation and pricing policy you should have had at launch, and publish it before you need it, so that the first time developers hear about your rules is not the day those rules cost them money.
And if a strategy change does require breaking a promise, break it the way you would want it broken for you: with a long window, a clear reason, a migration path, and a price that someone could actually pay. Reddit’s change might have been the right business decision. Apollo’s $20 million bill was the cost of making it look like the platform had never meant what it said.