An API Platform is Table Stakes for a Public API

An API platform is table stakes to build your public APIs on, especially if an API is a key part of your strategy, yet too often, API infrastructure is hand-coded, leading to short- and long-term trouble.

Offering an API publicly to partners and developers requires an extra level of polish. It requires approaching APIs like any other product offering that you’d release to the market. It means you want analytics, possible monetisation, a developer portal, customer support options, authentication and control. Ideally, you also want a way to manage your APIs without distracting valuable engineering effort. 

That is, you need to be able to run the API as a product within a business which means there is more to consider than just the functionality delivered. Like Google’s Apigee or Kong, an API platform provides the functionality and services needed to run API products and an API within a business.

So, why is it that API platforms aren’t used as often as they could/should be? Let’s work through a few generally taken perspectives, then look closer at the benefits of using an API platform. 

Technical Perspective on API Platforms

Due to the technical nature of APIs, most organisations and managers immediately turn to their technologists and engineers to understand how they need to deliver an API. What this amounts to is often a more technically skewed assessment of whether to use an API platform to underpin your API. 

The engineers will usually review the list of explicitly stated functionality and requirements then come back with a view that they can deliver on this with X weeks of engineering effort.

What often gets overlooked is:

• Unstated functionality that APIs need when offered publicly (e.g. documentation, analytics, support mechanisms and authentication);
• Technical aspects of deploying and managing APIs over their lifecycle;
• Engineering support costs (configuration, administration, etc.) 

So, assuming some or all of this is overlooked, then the actual time and effort invested in your API is already going to exceed what was planned. 

Some teams include these items but then engineers, being the smart folks they are, convincingly explain that they can easily develop the functionality offered by the platforms (I hear this especially with authentication). There are three common, major flaws with this argument: 

1. You don’t want your valuable engineering efforts invested in commodity functionality, like analytics. You need it invested in your differentiators and value creators.
2. While you may think you can build API platform functionality (e.g. authentication), it almost always blows out beyond what was planned when you start to uncover edge cases or need to make changes. 
3. Any line of code you write requires maintenance and support, which, linking back to the first point, means valuable engineering effort is wasted. 

There is a case to be made for avoiding platforms because of the complexity that they may introduce when a team is experimenting. When you’re trying to work rapidly very early on, then avoiding a platform can speed up releases and reduce complexity. However, platforms – if they are already implemented or if you’re familiar with them – can speed up experiments. So you need to work this case through for your specific situation.

Cost-driven Perspective on API Platforms

Another common perspective taken to assessing the use of an API platform is the cost perspective. The cost argument typically runs something along the lines of “we don’t have the budget to pay $10,000 to $100,000” for an API platform, so we will work around it. 

In all but pure startup situations, I’ve observed that this approach always ends up with months (sometimes years) of lost engineering effort and cost spent on low value, undifferentiated nuts-and-bolts API platform functionality. Put simply, 5-10x more is spent building what could have been purchased and leveraged immediately for a cost-saving and speeding up go-to-market on where your business creates value for customers.  

If you need to build a case for an API platform that comes from a pure cost perspective (some organisations listen more closely to this), then some costs to add to your engineer’s estimates are:

• Cost of engineering support (e.g. changing a configuration, API bundle or document)
• Cost of the overlooked functionality mentioned in the previous section (cost each item)
• Cost of lost time
• A fat amount of contingency

Benefits of an API Platform

In discussing the cost and technical perspectives on why API platforms don’t get used, you can start to see the benefits of an API platform. The world also isn’t always about risk; it’s about opportunity and benefits.

For API platforms, here are the key benefits:

1. Faster time-to-market: you can deploy public APIs faster and easier with an API platform. Once an API platform is deployed, this benefit becomes even greater due to the API platform providing the security, lifecycle and other behind the scenes features that enable you to deploy within an environment.
2. They’re kind of cheaper: once you factor in the real cost of hand-coding your own API platform, the price tag for a solid API platform isn’t that high and, in many cases, is substantially less. 
3. Focus on where you create value: no matter how many or little resources you have available to you; you need to focus on where you create value. Coding authentication or a developer portal is undifferentiated work. 

As the years have gone by, I’ve shifted away from a place where I would have avoided an API platform (we can get by, it costs too much) to a place where I’ll take an API platform in almost any situation for speed-to-market, realising the opportunity (instead of missing it) and focusing valuable team effort on differentiation.

Read more:

• The Complete List of Public ASX100 APIs
• The 37 Dimension API-as-Product Assessment Framework

---