A Guide to Picking the Right Business Model for Your API Strategy

by Igor Gorbunov, Senior Solution Architect, EPAM

May 22, 2017

An Introduction to Key API-Driven Business Models

Despite their increasing popularity, APIs in 2017 remain an item in transition: a technology phenomenon that has only recently received recognition as a business concern. As a result, IT and business sometimes do not have full consensus on what role APIs play in a company’s business strategy, and decisions about API business models are often made in a state of communication flux.

As with other strategic decisions, iteration and improvisation are often necessary to devise and fine-tune the API business model. Many startups embrace the “free at first, and then we’ll figure it out” principle, but most successful API providers agree that taking a deliberate approach to designing the business model improves the end result and reduces risk.

Here are some of the key API-driven business models and who uses them:

API Business Models chart by John Musser

 

The number of options is large and constantly growing, which will definitely prove challenging when it comes to determining which business model might work best for you. Continue reading as we offer a few guidelines based on industry best practices and our own experience.

How to Decide Which Business Model is Right for You

Some companies base their selection process on existing “industrial” methods, such as the Business Model canvas by Alexander Osterwalder. Most of the time, however, our customers opt for a less formal approach, seeking to narrow down their set of options based on the answers to the following questions:

1. What is the main purpose of your API, and what sort of outcomes are expected from your API offerings?

Mapping out the value chain helps in positioning the API correctly. The three major categories and their use cases are:

  • API as a product: This category implies that the API has a specific money-making goal or serves as a significant or single source of income for the company. By definition, APIs in this category must provide value that is easy to monetize, and is highly competitive or unique. One example of such an API is Thomson Reuters Knowledge Direct. As a premier provider of proprietary data, Thomson Reuters organically adopted a direct subscription-based monetization model.
  • API enhancing existing product: A majority of monetized APIs fall into this category. With the main money-making responsibility assigned to another part of the business, API providers have a greater set of business model options, ranging from direct pay-to-play to indirect, commission-based compensation. One well-known example of the indirect business model is offered by Expedia, as the Expedia Affiliate Network provides an API to book hotels and pays commission to any affiliate whose app or website was used for the booking.
  • API promoting existing product: Designed to solidify the market position, APIs in this category are often offered for free, and work to attract interest and traffic to the API provider. One example comes from Ticketmaster, who uses their popular Discovery API for exactly this purpose.

2.      What assets does the API provide access to?

Be it data, processes, or things, the nature of API endpoints often dictates which business models are feasible – and which are not.   Fully-automated, “digital” assets such as map requests, data queries, or even storage can now be offered virtually for free. This is an approach that Edmunds has chosen for their API strategy. They offer different tiers and quotas, but outside of registration requirements, all their data is offered for free.

Other assets have a specific, non-trivial value that naturally commands per-use payment. A famous example of such an intrinsically-valuable product is Walgreen’s Photo Prints API. They use call-based billing.

3.      Who are your API’s consumers?

  • Internal teams: This means that APIs are probably not going to be directly monetized, so just keep in mind that successful, initially-private APIs have a tendency to become public as they mature and their value is realized. If your API is expected to undergo such a transition, thinking about the monetization approach ahead of time is important.
  • Curated list of partners: Partner-only APIs provide access to internal resources that are business-critical, subject to regulation, or simply need more protective terms of service. Developer-gets-paid or indirect business models often rely on these sorts of partnership agreements. Alternatively, partner-only APIs can serve as a special tier for public APIs, like when one of EPAM’s customers opted to offer free unlimited use of their premium, normally paid API to select strategic partners. Regardless of the approach, it is important to remain balanced and keep track of your partnerships. As your organization develops, or the business landscape changes, some relationships may no longer make sense. In one case, for example, one of EPAM’s clients updated their whole partnership program after one of their partners became a competitor.
  • Wide external developer community: APIs in this category can potentially serve a very large number of consumers and generate a significant load. When deciding on a business model, special care must be taken with positioning your API for long-term viability, because retracting or making big changes to your public APIs is pretty hard to do. Additionally, besides traditional monetization concerns, security and load-protection mechanisms such as quotas, DDoS protection, throttling, and others should be the highest priority.

Where to Go from Here

Answering these three questions will likely present you with a more manageable subset of suitable models. Of course, the final decision depends on the specific business situation and requires a combination of thorough research, careful planning, and a bit of inspiration. That said, here are a few more tips to keep in mind as you flesh out your API business model and strategy:

  • Optimize for clarity: In a competitive and fast-moving IT universe, the ability to start painlessly and get results quickly is highly prized. Your developers/consumers will appreciate convenient documentation, clear terms of service, and intuitive pricing structure, which in turn inspires greater loyalty and faster growth.
  • Consider offering a free tier: Another measure for improving the developer experience is offered very frequently and is perceived as sort of a must-have by the experimentation-hungry developer crowd. Even a trivial “handful-of-calls-per-day” quota is very helpful when compared to a total lack of a free API tier.
  • Take care of API pricing consistency with existing product offerings: APIs that are priced dramatically differently than your other similar products may backfire by either cannibalizing more profitable channels or pushing away your loyal customers.
  • Try something unique or create your own mix of options: A lot of successful providers use different models for different products. They will change things up if they do not work out as planned. Your assumptions about your API consumers’ sensitivity may be overblown. For example, the CEO of the video-processing startup Ziggeo has recently told a story about their “dramatic” monetization change, which made a huge difference in ROI for the API provider, but was surprisingly silently absorbed by their customers.

I hope you found this information useful, and invite you to contact us with any questions. Also, keep an eye out for future blog posts where we’ll cover additional topics about APIs, including their evolution, strategy guidelines, program aspects, and exciting new technologies.