Real-World API Business Models That Worked

This year has seen an increasing level of maturity in API life cycle management for businesses of all sizes:

  • Startups increasingly favor API-as-a-product and API-first business models.
  • Established businesses are building organizational expertise in the API economy and are opening data and capabilities via API.
  • Enterprises are moving away from individual management of APIs toward organization-wide API strategic approaches, what Accenture calls Industrial API strategies.

As this has occurred, there is growing evidence among existing API providers around what works in creating business efficiencies, encouraging developer adoption (internally and among ecosystem partners) and generating revenue. However, it is difficult to quantify many of these benefits, as data on experiences is shared sporadically.

At ProgrammableWeb, we have had a long history in defining and discussing API business models, in great part thanks to the site’s founder, John Musser, whose seminal work on business models — and now more recently on metrics — is essential reading for any business embarking on a commercial API strategy. (In fact, on a panel hosted by ProgrammableWeb’s editor-in-chief, David Berlind, early this year, Musser asserted that any API provider must start with a business model or is destined to face uphill challenges at every step.)

In my work with ProgrammableWeb, I speak with API providers and startups regularly about their business models, but it has often been difficult to lock down any metrics on growth patterns or evidence-based factors that have led to success. As a result, there tend to be some assumptions we all take on — almost by osmosis — in the API sector. One of the biggest of these is that developer traction must be large: hundreds, if not thousands, of developers need to be on board for an API to achieve viability, for example.

Business Model Research Methodology

This year, ProgrammableWeb has carried out a research project into API business models in order to help tease out some of the critical success factors that have made a difference.

For example, what is the secret sauce that is causing APIs from WePay, Walgreens and SimilarWeb to see month-over-month growth in developer adoption and revenue from API channels?

Our study — which will be available in November — took a standard methodology to collate available (open) data about 15 APIs. This study has included:

  • Mapping each API business model with the business canvas methodology, using launchd.io to collate business components
  • Reviewing available data on any revenue growth or other metrics shared in articles, blog posts and case study reports
  • Collating comparative data on developer numbers by looking at support forum participation levels, GitHub follows, YouTube tutorial views, subdomain Web traffic (for developer portals, where possible), etc.

At APIcon UK, we were able to share some initial findings from this research.

1. Developer numbers don’t need to be huge

We often think in terms of hundreds or thousands of developers being a sign of API business success. But our study is revealing that it is quality, not quantity, that makes a difference.

It looks like 40 to 200 developer teams are enough to help APIs achieve significant growth in revenue.

Complementary to this, we are seeing that more API providers are taking a dual-carriage approach to developer onboarding. Many offer a self-service opportunity for curious developers and hackers who are interested in testing a business’ API. But much earlier in the onboarding process, we are seeing that successful API businesses are identifying those commercial developers who register for an API key and are providing a more personalized service to help these customers skill up quickly and make use of the API in commercial products and applications.

2. Business model clarity

I need to double check some of this data with API providers and their ecosystem partners, but I believe we are really seeing what Musser was so emphatic about on that panel earlier this year: To achieve growth, the business model must come first. API businesses that have clearly defined business and pricing models are signaling greater trust to potential developers, particularly those that may become commercial partners in a business’ API ecosystem.

In my work with ProgrammableWeb, I interview many startups that have a free-and-we’ll-see-what-happens strategy toward pricing. This is in strong contrast to what we are seeing among API businesses that are showing signs of growth. They may have freemium components, but the most successful all have clear pricing structures and agreements in place outlining who pays for API access. The one outlier in our study is a business that has a large enterprise customer base. In that case, it appears API adoption may be influenced by independent developers who want to service the API business’ enterprise clients.

3. Best practices are not uniform

We hear a lot about API best practices, whether that be design-first approaches, having the full gamut of developer resources (sandbox, code snippets, SDKs, tutorials, documentation, videos, etc.). We hear of the power and potential of using API description languages (Swagger, RAML and API Blueprint). And of the importance of discoverability strategies. Our research is showing that there is still a lot of room for API businesses to create a competitive advantage by instituting these practices. Many of the API businesses in our study are implementing only a few strategies so far and have plans to introduce more, but this could indicate signs of money being left on the table as business’ are not taking full advantage of the growth that comes from using all of the best practices in API design and delivery.

Real World Business Models That Worked is available for viewing on ProgrammableWeb’s YouTube and SlideShare channels. An e-book summarizing the business models research will be available in November.

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities.

Comments