Building Valuable APIs

The number of APIs and cloud services continues to skyrocket as more and more companies seek to get developers onboard with their services. All too often, a “build it and they will come” mentality guides strategy and marketing decisions for these products, leaving them in a crowded marketplace without enough differentiation, underlying value and visibility to succeed. We’ll cover technical factors of successful APIs in a future issue; for now, we’ll answer the question of how you can build a valuable API, which must be the foundation of any success. Hardly a day goes by without an announcement regarding a new API for mobile developers. ProgrammableWeb, a popular site that tracks APIs, now lists more than 6000 open APIs developers can use, with growth accelerating – it leapt from 5,000 APIs to 6,000 in its listings in just three months (for comparison, it took PW more than 2.5 years after its launch in 2005 to get to its first 1000 APIs). Meanwhile, all variety of cloud services are launching, from fully integrated backend-as-a-service platforms to push notifications to storage.

The situation isn’t totally dissimilar to what’s happening with mobile apps in appstores. The number of products is growing, the market is getting more crowded and it’s becoming more and more difficult to standout, particularly as the market is flooded with substandard products that make it hard for consumers to find the best solutions. There is a tendency to see this issue – whether it’s for apps or APIs – as a marketing or advertising issue, but it’s much more fundamental than that. Marketing does play a role, but it can’t be a crutch to overcome a low-value or otherwise poor product. The most fundamental aspect of an API or cloud service’s success is the value it delivers to developers.

Value is a function of two main components: the benefit a product delivers, and its cost. This raises two basic questions for API and cloud service providers:

  • What are the services developers want, and see benefit in?
  • How should the service be monetized and priced?

What do developers want?

There are a few ways to assess developer demand for APIs and cloud services. The first is to examine which ones are currently being used the most. It is very difficult to assess the most-used APIs in mobile apps, but research from the analytics firm Mopapp indicates that Twitter has one of the most popular APIs, with 63% of the top 200 free apps in the US integrating it (compared to 21% for Facebook).

We can take a look at the wider developer space through ProgrammableWeb’s directory of mashups and APIs, which indicates the following APIs are the most widely used in Web mashups:

  • Google Maps
  • Twitter
  • YouTube
  • Flickr
  • Amazon eCommerce
  • Facebook
  • Twilio
  • eBay
  • Last.fm
  • Google Search
  • Microsoft Bing Maps

(Note: this is historical data and should be seen as indicative rather than conclusive.)

This hits on some of the most popular areas: maps and location services, social networks, content, commerce, search and messaging, and match up with a recent IDC/Appcelerator survey that asked mobile app developers the cloud services they were most interested in connecting their apps to (see right).

Both of these sets of data should be taken with a grain of salt, though. They’re essentially backward-looking and focused on what’s already available in the market, rather than services or products that haven’t yet emerged. But they do show the general areas in which developers are looking for help from outside services and APIs: social integration and identity, storage, content (really social content, such as photos, reviews and sharing), and so on.

What is it that makes these areas so attractive to developers? It is their ability to deliver one or more key benefits:

  • Reach/audience – A service like Facebook, Twitter or LinkedIn delivers a large and valuable audience to developers, easing the path to adoption for their user base.
  • Ease of use/functionality – Services like login/account management or push notifications can be implemented by developers themselves, but require infrastructure investment, time or other constrained resources.
  • Access to valuable data or content – There are many kinds of useful data and content developers want to integrate into their apps, such as maps and location data, sports scores, videos, news content, music and so on.
  • Access to markets or monetization – If an API or service can deliver customers or revenues to a developer (such as through auction listings, affiliate sales or another means), it is incredibly valuable.

Focusing on these benefits (and being careful not to overestimate how you deliver on them) will help result in a valuable service. But a service that has value for developers is only part of the challenge; the other side is choosing a service that has value for your business as well.

One of the problems of developing services based on their presumed popularity from the above data is that it only looks at the demand side of the equation, and not the supply in the market. That is to say, while something like mapping APIs and services are widely used and highly popular, the market for them is also highly saturated and competitive, particularly for basic offerings. The same could be said for something like SMS messaging services, where the basic services offered are commoditized. Without being able to significantly alter either the benefit or the cost of services in these areas, they may not be attractive ones to enter.

A good example here could be Twilio’s SMS API. While it offers largely the same functionality as any other SMS API, operator or messaging aggregator, it was able to significantly increase the value of its offering over competitors by emphasizing and enhancing its ease of use. With all other factors held equal, it then becomes extremely competitive, even at the same cost level, as competitors.

What is valuable to your business?

Creating an offering that is valuable and attractive to developers is the key starting point, but that offering needs to be made attractive to your business as well. Capitalizing on developer demand for your service requires the right business model and monetization strategy.

WIP’s observation has been that many APIs and cloud services are typically launched with one of two models:

  • a per-dip model, where each function or call carries a distinct charge
  • a free model, with hope for some form of magical indirect revenue generation.

While both models have their merits, they must be correctly applied!

Before determining a business model and pricing strategy, you must consider the goal of your API. First, is it direct monetization? That is, is your API itself intended to be a revenue generator? This should be considered very carefully, simply because of the very high resistance many developers have to paying for APIs and related services. There are many reasons for this; it’s not simply being a cheapskate.

First, free options abound for many types of services, either because providers don’t know how else to compete, or a provider is choosing to monetize their API indirectly (if at all). Second, many developers, particularly in mobile, still struggle with monetization, and they simply don’t have the means to pay for APIs.

But another reason looms large: the decision-making process for developers at many companies, particularly anything bigger than small startups. While a developer may be the user of an API, and generally the one who finds and recommends it, they often don’t have buying power themselves, or the purchasing process takes a significant amount of time – in both instances, a free service will be simpler and easier for them to implement.

There are many use cases in which indirect monetization via a free API makes sense over paid API access, and this model is favored by many of the most-used APIs (Twitter, Facebook, Google, Netflix, Salesforce.com and more). These include:

  • Driving end users to or enhancing a paid service (such as Netflix, Salesforce)
  • Increasing traffic and audience for an ad-supported service (Twitter, Facebook, Google)
  • Content spread and syndication (NPR, ESPN)
  • Commerce (Amazon, eBay)

All of the examples cited above have a solid business model and monetization funnel beneath them; their APIs bring value to the business by filling that funnel, not by acting as a toll collector on it. That's a key point: an API needs to work hand-in-hand with the goals and models of the business of its provider, and the belief in being able to monetize developers directly shouldn’t override that.

API Business Models

Source: ProgrammableWeb

If the decision is made to directly monetize an API, the default thinking is generally to use a per-dip model, in which the developer is charged for each call or transaction (such as a map lookup or SMS sent). Why? Because it’s easy and its pay-for-what-you-use nature seems good and fair. However, as noted above, this model is often misapplied.

It’s important to consider this model from the developer perspective: if I’m being charged on a per-unit basis, can I reasonably monetize each of those units? More often than not, the answer is no, and furthermore, this choice often forces developers to choose between the best user experience and financial safety.

The models typically used for SMS and push notifications provide a good example of this. SMS is typically billed per message, while Urban Airship, a leading provider of push notifications, has service tiers based on an app’s number of active users (see right). This means a few things for developers:

  • They have predictability over monthly charges, are aren’t held hostage by the growth of their services. With a per-dip model, user growth comes at a very high price.
  • They can focus on monetizing users and apps as a whole, not trying to monetize individual items or services within an app on a per-use basis.
  • They can integrate push notifications how they see fit for the best user experience, rather than integrating messages on what they can afford.

For high-volume services, a per-dip model is often a bad one. For services that will be consumed by an end user as part of a subscription or as a part of a larger app, they’re often not a good idea. Keep in mind that on platforms like iOS, subscription billing is difficult, if not impossible, complicating things further.

But with all paid services, regardless of model, the concept of runway is an important one. Whether through a sandbox, free trial or a freemium offering, it is essential that developers have the opportunity to explore and use a service without a significant financial commitment. This is important for developers at large companies, given the buying process constraints noted above, as well as for smaller developers, who face financial and monetization constraints.

Conclusion

The key to a successful API offering is value, both for the developer and for the provider. When building developer value, focus on maximizing one or more of these key benefits:

  • Reach/audience
  • Ease of use/functionality
  • Access to valuable data or content
  • Access to markets and monetization

Maximizing the value for your business relies heavily on choosing the right business model and pricing strategy, particularly the decision to directly or indirectly monetize your API. Incorrectly matching your business model and/or pricing structure to the use cases of your app will have a negative effect on value to developers, and undermine your efforts.

January 2014 New Developer Tools

Google Play Releases 4.1, Improved Features The latest release of Google Play includes new features that not only provides Turn Based Mutliplayer support for games and preliminary API for integrating Google Drive, but also improves battery life for all users with Google Location Reporting enabled.

The Turn Based Multiplayer support allows developers to build asynchronous games to play with friends and auto-matched players, supporting 2-8 players per game. The release also includes a developer preview of the new Google Drive API for Android, which allows  users to easily read and write files in Google Drive across all devices on the web. Users can also work offline with the security of knowing that changes are automatically synced with Google Drive when they reconnect.

From a publisher standpoint, Google Play Services 4.1 allows increased support for DoubleClick for Publishers, DoubleClick, Ad Exchange, and Search Ads for Mobile Apps through the Google Mobile Ads SDK. Additionally, the Google+ sharing experience is also more efficient through the use of auto-complete and suggested recipients from Gmail contacts, device contacts and people on Google+.

imgble

Imgble is an online service that formats a specified image to best fit in different mobile screens. The tool's API allows users to submit images for reformatting, specify the height and width, the output format, and add over 20 effects to the image. Best of all, the API is free to use.

Macy's Mobile Utility Services API

Macy's offers a variety of APIs that provide access to different types of content and services, including the product catalog, store events, promotions, coupons, registries, user profiles, and more. The Utilities API allows developers to programmatically manage mobile options. Users are able to opt in or out of mobile options, log mobile activity, or retrieve configuration files for a specific mobile app.

KidoZen

KidoZen is a mobile application backend-as-a-service platform, which allows mobile application developers backend solutions for existing applications and for building an managing new applications. The API and SDK allows developers to access and integrate the functionality of KidoZen with other applications and create new ones. Some API methods include account management, application feature management, and user management.

ZowPow Toys

ZowPow Toys brings together physical toys and mobile technology by allowing children to play with physical toys through mobile technology that brings them to life. The API and SDK allows developers to access and integrate the functionality of ZowPow Toys with other applications and create new ones.

appercode

Appercode is a universal application platform for smart devices that allows developers to unify platforms across devices for their applications. The API allows developers to unify platform-dependent parts of mobile applications' interfaces and empowers C# developers to create fully native cross-platform mobile applications more efficiently.

Fleksy

Fleksy is the first keyboard app to arrive on the iOS platform that replaces the native keyboards on smartphones and tablets by opearting on a predictive text technology. The API and SDK allows developers to access and integrate the functionality of Fleksy with other applications.

Applause Analytics

Applause is an analytics tool that measures mobile app quality and user satisfaction by grading across ten attributes, enabling companies to compare their apps version to version and against the competition. The API provides developers access to the analytics platform. The API is able to search for apps and deliver descriptive or factual information, review, and aggregated Applause statistics for a given app.

Mendix

Mendix is an open mobile application building platform that allows users to seamlessly integrate with common software development and testing tools. The API allows developers to access and integrate the functionality of Mendix with other applications.

Captain Pass

Captain Pass is a web service allowing businesses to build, distribute, and manage PassBook Passes. The Captain Pass API provides a RESTful interface for creating, delivering, and updating passes. The API is able to create passes such as coupons, tickets, store cards, member cards, and transport tickets, for all major mobile platforms.

MobileDevHQ

MobileDevHQ is a mobile application marketing platform. MobileDevHQ offers various features and services to application publishers, marketers, and developers to increase application downloads. The MobileDevHQ API allows developers to access and integrate the functionality of MobileDevHQ with other applications.

Lipisha

The Lipisha API was created to allow users the ability to easily integrate the payment system. The API carries out a number of activities including creating a new payment account, querying for transactions, Sending mobile money, charge a credit or debit card, transferring funds between different Lipisha accounts, and more.

Bestly 

Bestly is an A/B testing platform for native mobile applications that aims to make testing new app variations easy. The service enables users to easily make data-backed decisions about about application variations with confidence. The API allows developers to A/B test anywhere. Resources include Experiments, Trails, and uuid. All data is sent and received as JSON and an API key is required.