Jeff Bezos’ API mandate: What the five rules mean and do

In 2002, Jeff Bezos issued what is now known as the API mandate: The new direction at Amazon would be that all capabilities would have to be designed and exposed as APIs. This is an early version of what we today call API First. Most importantly, the mandate had a laser focus on the fact that APIs need the network effect to produce the most value, and thus it simply said that APIs are not optional anymore.

The original mandate is preserved in a GitHub Gist that captures a reaction to it, which is Stevie’s (Steve Yegge’s) famous Google platform rant.

Let’s have a look at the five rules that the mandate put in place, and what they mean.

Data and Capabilities must be exposed through APIs

This rule makes it clear that “specific integrations” are an anti-pattern, and that instead, APIs are the way how all capabilities are exposed and consumed. Making this the first rule makes it clear that APIs are not an optional aspect anymore, but that they are a mandatory part of building anything.

Team Communications must be through APIs

For scalability, it is important that teams can collaborate without having meetings. Instead, the model is that by publishing an API, a team clearly communicates what it has built and what it offers, and other teams can build on that. If you can avoid having meetings for every new connection between features that are created in an organization, implementing new features is faster, and it scales better. This second rule establishes an API product mindset, with all products being designed as a consumable commodity.

There can be no side channels/shortcuts

APIs are not always easy to design and implement, and thus there always is the temptation to forgo APIs and use other mechanisms instead. This third rule makes it clear that APIs are the strategy going forward, and that there is no leeway to decide against them for whatever reason. By disallowing the bypassing of APIs, it’s made certain that absolutely all capabilities indeed are designed and accessible as APIs.

Technology choice is secondary

While this may come as a surprise to some having a technology focus, this rule acknowledges that the main value of APIs is in their very existence, and not in the technical details of how they are designed and implemented. Notice that this rule does state that technology is irrelevant. It still matters to choose technologies that are working well for the intended consumers, and to design good APIs for that technology. But what’s most important is that there is an API, so how it is designed and implemented does become secondary.

APIs must be externalizable

While not all APIs will be made available outside the organization (to partners or to the public), for some that will happen. It should be a business decision to expose an API outside of the organization or not, and therefore all APIs should be designed so that they can be externalized should there be a reason to do so. Because it would disrupt existing API consumers if the API had to be redesigned in such a case, it is important to design all APIs to be externalizable. This fifth and last rule makes it clear that an organization’s APIs should allow it to participate in the API Economy, where strategically exposing APIs to partners or the public is part of the way the business is managed.

What this means for organizations and their API strategy

In summary, the five rules of the API mandate are doing a very good job of making sure that APIs are not treated as technical artifacts, but that instead APIs are established as part of the general strategy of how the organization will grow and adapt and change. While the mandate is almost 20 years old as of today, it seems that many organizations today still have not quite reached that level of commitment to taking APIs to the center stage of their strategy.

One important thing to keep in mind in this context is the network effect. A good part of API value is created via the network effect: The more capabilities are available as digital building blocks, the more fertile this API landscape becomes for valuable things to be built on top of it. This means that populating the API landscape is an important precondition for API economies of scale to work, and with the API mandate in place, Amazon made sure that the richness of the API landscape is a top priority for the organization.

If you’re interested in a conversation discussing the API mandate and its reasoning and goals, feel free to watch the following conversation with Mike Amundsen where we discuss the five rules in more detail.