John Musser knows APIs. As the founder of Programmable Web, John has witnessed thousands of APIs and many business models. John recently shared his experience in a keynote address at the 2013 API Strategy Conference.
The most frequent question asked of John is "how do you make money from this?" The answer depends on why..."why do you want an API?" There are many reasons to have an API and this leads to the first of John's five API secrets that he discloses in the keynote, "an API strategy is not an API business model". An API strategy is about "why" you want an API and a business model is about "how" you make money from it.
Looking back to 2005, the beginning of APIs and the time when Google Maps took off, there were four core API business models: "free", "developer pays", "developer gets paid" and "indirect". Today in 2013 there are still the same four core business models but each has expanded into a variety of different ways to provide and monetise APIs. John's second secret is that "most APIs have more than one type of ROI."
For the remainder of his address, John takes a deep dive into each of the core business models, starting with "Free". Contrary to popular belief, "free" is not the predominant API business model. John cites Facebook as an example plus all the government and public sector APIs, but these free APIs are only a "tiny fraction" of all API business models.
The next category John describes is "developer pays" where application developers pay for the services provided by the API. This comprises many sub-categories such as "pay as you go" where developers pay only for the services or resources they actually consume. John's example here is Amazon Web Services which states in its pricing plan: "Pay only for what you use. There is no minimum fee." A second sub-category, the "tiered" model offered by companies like Mailchimp provides lower cost per unit as you consume higher volumes of their services. "Freemium" is a well known model where basic features are provided free but for a fee you add services such as additional APIs, higher SLAs, an account representative etc. John cites Compete and Google Maps as examples of the freemium model. "Unit-based" pricing is another sub-category such as Sprint's offering where different features in the API attract different charges. The final example of "developer pays" is the "transaction fee" familiar to users of payment APIs where a percentage of the transaction is charged. John cites PayPayl, Stripe and Chargify as examples of this model.
The converse of "developer pays" is the "developer gets paid" business model and that is the next category that John describes. This category also has many sub-categories such as the "affiliate revenue share" model offered by Amazon Affiliate Program where developers are paid for customer referrals. Another sub-category is "revenue share" where developers are paid a share of the revenue from referring purchases. John gives the example of mysimon.com and howstuffworks.com, comparison sites which use shopping.com APIs to support product comparisons and then gain revenue share from click-throughs. John notes that affiliate revenue share is not a "small business." Expedia derives 90% of their revenue from an affiliate network using Expedia APIs which represents $2 billion per year. Finally there is the "recurring revenue share" model used by companies such as rdio.com where affiliates who refer new customers for subscription purchases are paid a revenue share for the life of that customer.
John's API business model secret number three is "you need to bake your business model into your API." This is the biggest secret that John wants his audience to go away and think about. For example, the Amazon affiliate programme was a natural extension of their retail business model.
Out of the original four core business models, John now discusses the "Indirect" category which he thinks contains some of the most interesting ways to monetize APIs. The first sub-category is "content acquisition." Businesses like eBay and Twitter need to rapidly acquire content in order to grow, so they use APIs to facilitate content acquisition. eBay APIs allowed power users to create mass listings in the eBay marketplace. Twitter derives and distributes content almost exclusively through APIs and third-party applications. "Content dissemination" is the next sub-category, where the New York Times has lots of content and utilises APIs to syndicate that content to partners.
SaaS up-sell is another business model within the "indirect" category. Salesforce.com offers API access to their platform, but only for companies that pay the enterprise licence. Salesforce.com knows that API integration is important and uses that to upsell customers into higher subscriptions. John characterises APIs as "the glue of any SaaS." Integration adds value to SaaS applications and provides a stickiness factor that dramatically reduces churn. John's API business model secret number four is "API business models are not one size fits all."
The final business model John presents is the "internal use" model where companies use APIs to support their own business. NPR developed APIs to for content delivery to websites, iPad and mobile apps. Over 99% of Evernote's API traffic is from iPad apps, mobile apps and partner apps. And Netflix uses its APIs to support content delivery to over 800 different kinds of devices. Hence John's fifth and final API secret is that "internal use may be the biggest API use-case of them all."
About the Author
Saul Caganoff is the CTO of Sixtree, an Australian system integration consultancy. He has extensive experience as an architect and engineer in major integration and software development projects in Australia, the United States and Asia. Saul's professional interests include architecture at all levels - enterprise, solution and applications - distributed systems, composite applications, cloud computing and cloud APIs.
