The Keys To Successful Real World API Strategies

This is the final part of our series on 8 Real World API Strategies and The Keys To Their Success.
 

Key Findings

The following are common growth strategies being harnessed by the eight API leaders documented in this research report. As the case studies show, many have followed a similar trajectory, introducing more sophisticated tools and techniques as they continue to onboard commercial third-party developers and scale out their ecosystem.

API Developer Support

When selecting these cases studies, we focused on APIs that had already followed best practices in API development. For example, the providers follow API-first design principles and offer a range of developer support resources that usually include:

  • Interactive user documentation
  • One-step registration to create an account and begin trialing an API
  • A sandbox environment
  • Tutorials
  • Developer support forum.

In addition, most of the API leaders included in this report offer developers the following resources:

  • An API Status page: In order to build trust and confidence with ecosystem partners, leading API providers shared their uptime status via an API status page.
  • Specific developer/engineering Twitter accounts and blogs: Several API providers have created a separate engineering blog to provide more detailed discussion of code snippets, new SDK releases and coding techniques for using their API. Most have also introduced a specific Twitter account that targets their API developer communities to enable quick response to issues and to provide another mechanism for alerting developers to server status updates.
  • Open-sourced SDKs and Ruby Gems: SDKs are often considered a ‘time to hello world’ shortcut for those developers wanting to quickly assess an API before integrating it into their coding projects. The best of the API providers here publish their SDKs as open source tools and Ruby Gems, and encourage developers in their community to also build tools off these resources. APIs like Contentful and Edmunds regularly promote developers who have built their own Ruby wrappers and other tools. Enterprise IT thought leader Dion Hinchcliffe notes that this is one of the key differentiators for successful digital businesses: They acknowledge that, to succeed, they must tap the most value from their networks, leveraging the idea that “anyone can participate.”

Size of Developer Community

Contrary to popular thinking, developer community numbers do not have to be particularly large to start having a network effect.

Overall, the majority of APIs in this research experienced a similar pattern of engagement:

  • 100% of developers register for use of the API and visit the developer portal.
  • About 10% of these developers are then active in the community. This is usually seen in SDK download levels, and in the level of activity in online support forums--for example, where data is shown on number of developers who have read a particular forum post.
  • About 1% are actively creating commercial apps or are certified API partners. These developers are highly focused on monetizing their use of the API by becoming experts that can be hired to work on consultancy projects, or who have created third-party apps and integration products that they then sell separately to end users.

Effective Business Models

Among the case studies documented here, business models were split between some form of developer pays: either via transaction fee (WePay), for tiered usage (Contentful and SimilarWeb), or on a unit-based pricing model (TransportAPI). Among those offering revenue share to developers, the more mature APIs--such as Walgreens Photo Prints API and Edmunds APIs--had clearly calculated revenue return rates. Those entering the market more recently, in contrast, provide freemium API access, allowing developers to monetize the products they create using the API (Podio and Philips Hue).

Effective business models

Developer Pays business models tend to be used by API providers where the API consumer is either the end user or is using the API as a tool to deliver a service to an end customer. WePay uses a “developer pays by transaction fee” model, as its API is a payment gateway service that enables the API consumer to provide a better service to their customers. Contentful uses a tiered developer payment model, as consumers use that API as a way to deliver content seamlessly to their end users. TransportAPI charges for API calls, where API consumers are often mixing this data stream with other data and services to provide a holistic, hyper-local service to their end customers.

Revenue Share business models tend to be focused on developers that can help extend the reach of the API provider’s business into new markets. Philips Hue encourages third-party developers to commercialize applications that extend the value of their programmable light bulbs and therefore make them more valuable to a larger number of potential consumers. Podio promotes developers who are creating ancillary tools that extend the value of Podio to enterprise customers. Walgreens shares revenue with app makers, which helps the company increase its brand reach and customer utility such that mobile app customers spend 3.5 to 6 times as much as in-store customers only.

Developer Onboarding

Many API providers are moving to a point where they can immediately recognize which of the developers registering for an API key are hobbyist users and which are seeking out commercial opportunities. SimilarWeb, for example, has built an Excel spreadsheet using the Rapportive social media account API to automatically list all emails from newly registered developers. Each email is then looked up against the Rapportive API, and additional data about each new registrant is added to the spreadsheet. For example, a registrant’s job title might be added. When the job title reveals a specific developer management role--such as lead developer or vice president--then SimilarWeb’s API evangelist team focuses on on-boarding to make sure these high-value API consumers have opportunities to discuss potential use cases and make use of the API in a hands-on way.

API Discoverability

API discoverability is a difficult measure to analyze. This is partly due to the strong evangelism component that many of the API providers are taking. Edmunds and Walgreens, for example, have a high level of website referrals coming from the brand name searches “Edmunds API” and “Walgreens Photo API.” This suggests that the in-person developer evangelism that is being led by both companies — their presence at conferences and industry events, hackathons and meetups — is building API product brand name recognition which is translating into Web searches.

Many of the APIs covered in this case study also see a consistent long tail of new website referrals sourced from ProgrammableWeb’s blog and API directory, as well as from SaaS directories and GitHub.

For the majority of the APIs included in this report, the final months of 2014 began to show some increases in the number of website visits coming from searches for more generic API-related keywords. For example, Contentful is seeing growing website visits from searches for the term “CMS API” and, as the automotive industry takes up a more digital focus, the number of searches for “VIN Decoder API” has risen (a data source that describes a vehicle based on its identification number). While this data has been around for several years and offered through Edmunds APIs, it has only been in the second half of 2014 that searches for this term have risen enough to flow in as new referrals to the Edmunds developer portal website.

Several of the leading APIs in this report are also seeking to move beyond just owning the keyword terms related to APIs, but instead to be at the forefront of their industry. WePay is positioning itself well to appear in searches for platform payment methods, while Contentful is seeking to increase its reputation in the field of “content orchestration” and for broader content delivery management industry terms.

Partnerships and Marketplaces

A successful API nurtures the success of its customers (developer-consumers) and the businesses they are building that make use of an API. After splitting developers into hobbyist and commercial onboarding processes, several of the successful API providers showcased in this research report then began to build personal relationships with commercial developers to help them create viable products that are built using their APIs.

In 2014, many of API providers showcased in this report also began to single out intermediaries who would be using the API with their client projects. Podio, Contentful, Edmunds and Philips Hue all promote developers who are highly conversant with their API.

Edmunds has perhaps one of the most sophisticated developer marketplaces. The company encourages two types of API consumers: businesses that may want to integrate the Edmunds APIs into their products and services, and developers who could work with those businesses to optimize using the API. Developers can pass a series of API related exercises to register as certified API developers.

Edmunds, Podio, and Contentful all have well-promoted co-marketing strategies aimed at driving lead generation towards third-party developer consumers.

Alongside promoting expert developers who can help other businesses build products that consume their API, the majority of the API providers in these research case studies also promoted and showcased apps and products built by third-party developers.

Podio, Edmunds and Philips Hue have app market sections of their websites where they promote external products built with their API, and allow direct revenue generation for those app makers. For example, Podio hosts an API Integrations page that links to the websites of commercial products — like Globiflow and SmartGantt — that are sold as separate business tools for Podio users. Seventy-five percent to 90% of referrals to these product sites are from the Podio website. Philips Hue links directly to app marketplaces, including the Chrome extensions store, to allow developers to sell their API-enabled products directly to end users.

Other API providers like Walgreens, TransportAPI, WePay and Contentful regularly publish blog posts that highlight how customers and app developers are creating products built on their API. Walgreens also heavily co-markets apps created with the API via its blog and dedicated API Twitter account.

Tools, Tutorials and Integrators

With the above strategies in place, the majority of API providers researched for this report are seeing monthly climbs in the level of engagement on their developer portals.

The next stage in encouraging API uptake is then to extend access to the API in new ways that require less technical expertise. Edmunds, for example, provides code snippets so that end users can embed widgets directly on their websites that call the API when making car sales quotes. Edmunds offers an affiliate commission via Commission Junction for any website using this API-driven widget to funnel site referrals to the Edmunds main website. Walgreens’ revenue share for photo printing is also channeled through Commission Junction.

SimilarWeb has one of the most sophisticated API toolsets available for non-developers. The organization has created a series of Google Docs that provide the sort of data tools that potential API users would need to build themselves. Users can download the Google tools for free, but — just as they would have to do if building the tool directly from the API endpoints — they need to register for an API to feed data into their spreadsheet tools. Heavy users of these tools then pay the API access fees in line with their subscription plan, but without the heavy lifting of having had to create the tools themselves.

SimilarWeb has also built Google Tools that include website data collation spreadsheets, keyword ranking tools, traffic estimators and media buying tools. Other API providers could follow a similar strategy and create the sorts of tools, dashboards and data analytics products that customers in specific verticals would need to build themselves with the API.

A number of API providers are using similar approaches to extend their reach: Contentful, for example, is introducing WordPress and Drupal importers to better enable content from previous legacy systems to be integrated with its API. They have also created several IFTTT and Zapier integrations, as have Philips Hue and Podio.

TransportAPI has built experimental tools that demonstrate the potential of using its API. TubeRadar is a map-based product that uses TransportAPI’s data feed to visually show, in real time, where Greater London’s public transport options are running on time, facing delays or have had routes cancelled. They have also integrated with mapping, sentiment analysis and Twitter APIs to create TransportBuzz, which provides real-time commentary of people’s experiences on public transport. While not yet commercially focused, the idea is that these products demonstrate the potential of using the API. Contentful also has a small app showcase with sample products.

An emerging strategy now being deployed by some of the most effective amongst these case studies is a new set of developer support resources that speak beyond the technical aspects of an API and address how a developer consumer could enter the market by creating a business built on their APIs.

WePay, for example, provides tutorial resources not only on how to use the API, but also how to establish a marketplace or platform-based online business that would then need to use the WePay API product when it launches. Similarly, Contentful is reframing its product in terms of how businesses can specialize on content orchestration, while TransportAPI discusses the emergent out of home digital display sector.

In each of these cases, the API providers are recognizing the need to provide resources that speak to the broader business of a potential API consumer, as well as more directly to the API developer technician.

Replicating the Ecosystem Growth of Successful API Businesses

API ecosystem growth model

While each of the API case study companies in this research report have pursued its own trajectory, a fairly common growth hacking strategy has emerged that builds more sophisticated levels of resources as API engagement grows.

  1. This process begins with best practice API-first design and high quality developer resources.
  2. API providers then communicate a clear business model,  
  3. 3 & 4 focus on discoverability.
  4. SDKs are open sourced to enable other developers to add tools and contribute to the growing community around the API. 
  5. As developers become conversant with the API, marketplaces are promoted (for both expert developers and third-party apps).  
  6. Finally, non-developer use of the APIs becomes a focus, with new tools built that enable customers to consume the API without having to code for themselves (with tools like widgets, Google tools and IFTTT/Zapier integrations),
  7. Tutorials and content that speak to the wider industry verticals the API is operating in.

Note on Methodology

A detailed discussion of the methodology used in this research will be published on ProgrammableWeb. Please note all data for this report was collected and updated to be a snapshot of API growth, as of March 2015. This allowed for use of SimilarWeb data for the 12 months previous as its algorithm changed in April 2015. All SDK downloads and social media counts were also updated as at that time.

Acknowledgements

Jack O’Hurley
Holger Reinhardt
Noam Schwarz
Sascha Konietzke
John Musser
Joe Rago
April Rassa
Scott Feinberg
Jonathan Raper
Emer Coleman
Ismail Elshareef
Jim Naylor
Kevin Toms
Thomas Stensbol
Martin Muentzing

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

Comments