Four value propositions for APIs

When you’re thinking of offering an API as part of your own product, you should take some time to understand how to position its business value proposition in a way which makes long term sense. With a clear value proposition it will be much easier to justify the investment and maintenance resources an API requires.

Offering an API to outside users is a commitment to continue providing it. In order for that commitment to make sense, it must be valuable to your business, too. Similar to SaaS products, API value propositions fall to a few general categories. Naturally, the value proposition towards the API’s vendor and its customers could be different, but that’s often a source for priority conflicts and businesses should try to align to the same value proposition they offer to customers.

The clearest value proposition is direct revenue. Some of the most successful API businesses are pure revenue generators — a typical example is Stripe, which entered the payment gateway market as one of the first to focus on ease of integration with a clear API and streamlined activation process. A revenue generating API has an obvious transaction fee business model.

The second value proposition is ability to reach new markets or customer segments. In this category, the clearest examples are various programmatic advertising platforms offering targeted customer acquisition capabilities (Google, Facebook, and so on). APIs of this class are often priced by delivered reach, while their predecessors’ pricing was predominantly volume-based.

Many software products have a primary value proposition around increased efficiency and cost reduction. I tend to think that all API offerings include this component, as they’re all designed to automate something that would otherwise require labor. As such, unique value proposition around efficiency is hard to define for APIs, and combining with the difficulty of measuring costs saved, this is not a model well suited to structuring API value propositions.

On the other hand, increased productivity, a value proposition that is often behind SaaS products with high growth and long-term success, is very suitable for API offerings. In the API world, the most direct way to measure and show productivity increase is through business process cycle time: how something that used to take two days (or weeks!) can now be completed in ten minutes. This promise is the driving force behind the Bitcoin/Blockchain enthusiasm, success of AWS and other cloud computing platforms, nearly every DevOps tool and much more. It’s very easy to also price such an API based on usage volume: higher volume directly correlates with the volume of the accelerated business process.

The fourth and final major value proposition category for APIs is predicated on value of data. This value proposition drives adoption of both tools like Mixpanel, which usually are priced by the volume of data processed through the API, as well as the data-focused PaaS offerings of major cloud providers (also priced either by amount of data or by volume of access to it). It is also behind many of the apparently-free platforms, where the API collects value to its vendor by collecting data from its users. The latter model of course is quite familiar to us from many consumer SaaS apps, and indeed these APIs are often connected to those apps, for example Foursquare.

While it’s easy to see components of two or more of these value propositions in many products, including many API offerings, understanding its primary driver is critical for setting the right pricing for the API. For example, placing a metered-volume pricing structure on an API for which a key value driver is the ability to collect data for analytics re-sell would be a clear mistake — yet one which has been repeatedly implemented due to lack of forethought.

Like what you read? Give Osma Ahvenlampi a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.