APIs…? But Where is the Value?

APIs are cool! We know that, but why do we need them? Where is their value? In order to answer this, we need to look at the API value chain.

Unlike other products, like websites, APIs have an indirect value chain. Websites directly expose information and services to their end user. APIs on the other hand, expose information to other developers, in order to build applications, that pass along those resources to end-users.

API value chain

What really determines the value of an API is the underlying business assets. In order to consider creating an API we must have some resource that would provide value to end-users and/or developers. From the perspective of the asset owner, being altruistic is great but most resource owners expose their assets because they also see some personal value to be gained from creating an API.

The API is the next step in the chain. It is the tool by which the resource owner exposes their assets to the developer. At this point, their goal is to satisfy the needs of the developer in order to ensure the assets are consumable and put to the best use.

Once the API is created it is up to the developer to use the API to create applications. The applications are what provide value to the end-user. The development team needs to make sure that the application is easy to access, whether through app store, download, web app, or other means. Through this process the API provider delivers the valuable business assets to end-users, through developers and their applications. If an API is not as successful as expected there is a good chance that one of the links in the value chain is weak and needs to be fortified.

There are essentially two ways to use APIs: publicly and privately. These two methods are by no means mutually exclusive, in fact, many API programs can best be described as an iceberg. The APIs that everyone is most familiar with are public APIs but under the water are many, many, more APIs that drive the company’s business. In fact, if you were to dive beneath the surface you would often see that it takes several private APIs to support the public API.

“This huge mass underneath the water that you can’t see, the private API, is the biggest part of the whole opportunity.” — Daniel Jacobson

So lets take a look at some of the ways a private API can provide value. First off we need to understand how the value chain changes when we are talking about private APIs. The business assets used in a private API wouldn’t provide value if exposed publicly or would be legally limited (think NPPI or proprietary information). The business owner, API provider, and the developer have open channels of communication because they are at the same company. This is important because it creates an active feedback channel between the API provider and developer. The feedback allows the API to be molded to best fit development needs. Finally, maximizing the benefits of internal APIs requires leveraging different marketing, promotion, and distribution channels.

One way a company can use private APIs is to create a public application. While a company may not want to allow outside access to its customer billing data, APIs that provide that information are an important piece of their mobile application. The API allows the internal development teams to easily access the data required for their external application without having to develop their own billing solution.

Additionally, private APIs can support the development of internal applications. One example is an employee information API. This data is probably used for any internal application that provides user specific content. Companies like Workgrid rely on internal APIs to integrate with their client’s underlying systems and provide a central digital assistant for their administrative needs.

Private APIs also allow companies to work more closely with partners. There are two main ways to do this. The first is to use private APIs to create applications that address the partner company’s integration needs. The second is a semi-private model where you expose your APIs to the partner company. You aren’t giving the whole world access (yet) but it is no longer just an internal API. This model helps to build close working relationships with business partners.

Just like the Titanic found out there are also risks hiding under the water. As powerful as private APIs are they can easily be misused reducing their benefits. One big mistake people make is not treating all developers equally. Just because you are paying the developers who use your API, do not assume they are fundamentally different from external developers.

“The power of an API diminishes dramatically if the only people who can use it are the experts who created it. For an API to be truly useful, it must be productized so that others can use it themselves. Using an API internally does not change this principle…” — Daniel Jacobson

The API should be designed and documented so it is easy for your developers to use. Just because they work at the same company as the API providers we shouldn’t assume any extra familiarity with the product. Additionally, internal APIs need to be marketed as much, if not more, than public APIs. To reap the reward of APIs, people need to use them, and to do that developers need to know they exist.

If you can navigate around the risks, the benefits of private APIs are as massive as an iceberg. It allows for the speedy development of scalable, efficient, and content rich applications. Business relationships also benefit by enabling better integration and industry disrupting efficiencies and capabilities.

If we shift our focus to public APIs we are talking about instances where we want to expand the audience of the business assets, in order to use them in ways that are not possible, or efficient to accomplish internally. The developers are more diverse, and it is harder to get their feedback. The API provider will have to work extra hard to meet the developer’s needs. Regarding the final link of the chain, the application, the API provider has truly limited control of what is created or how it is distributed, which makes it hard to ensure the strength of the whole value chain.

A lot of the benefit of a public API is allowing for the creation of something unexpected, or innovative, as the kids are calling it these days. An analogy that may help understand this comes from the small soap company, Kutol products. The McVickers family created a salty clay that was an effective wallpaper cleaner. Through public consumption and feedback from McVickers’ son (a genius developer) the clay was given to preschoolers for a fun playtime activity. It eventually became know as Play-Doh. This lighthearted story has a powerful message about your public developer community. If you give them the latitude they can transform your product into something unimaginable and make your services survive longer than the wallpaper it was built for.

Besides product longevity another thing associated with value, is cold hard cash. I don’t want to dive too deeply into this topic, because it should be its own article, but you can charge developers to use your API. There are a number of different pricing models: fixed rate, tiered pricing, usage based pricing, etc. The Mozscape API has a great example of tiered service and quota based pricing, if you are curious. The key fact here is that your public APIs can generate revenue which is valuable to the company bottom line.

Public APIs are also great at extending the company brand. I’m sure you have used a mobile or web app and noticed that the map is powered by Google. Google has a public maps API and now when you think of online mapping you think of Google. Their maps are used everywhere, not just on Google applications. By exposing your APIs publicly you allow outside developer to do marketing for you. Whether it is the logo on the search bar you provide the data for or the popularity of your API in source code on GitHub, your developers will help you spread the word about how valuable your services are.

The enhanced brand awareness can also effect recruiting. One reason that Google and Amazon get a lot of top IT talent is because they are everywhere. If you search for an error code, you probably use Google. If you buy a new monitor, you may end up on Amazon. If you want to create an API you may spin up an AWS instance. If you are building a mobile app you probably deploy it to the Google Play Store. One way to get your brand out there is through APIs. Developers will know your name if they are building applications with your services and seeing your products every day. The advantage of this type of recruiting is that it is very targeted. Your consuming audience is a self-selecting group of developers, who find what you do fascinating and valuable.

“With great power comes great responsibility.” — Ben Parker

Uncle Ben was clearly talking about APIs and the responsibility to address the risks that come with public APIs. First of all the more you expose to the public, the greater the risk of attack. These hooks that allow developers to use your systems also expose your system to unwanted guests. This is why security is an important aspect of every API (another topic too large for this article). Another risk is, thinking the value is in the API, instead of the business assets. Each link in the value chain is important but without valuable business assets the chain cannot exist. No matter how simple and consumable you make your API, if the underlying resources aren’t valuable, developers will not use it. Finally, it is important to make sure that people are not misusing your API. Create a Terms of Use contract and make sure developers follow it. This could include items like required branding or limits on the age of the end user. Remember it’s your brand that is being put out there so any negative activity could effect the company’s image.

These risks are why companies don’t generally start with public APIs. They first create private APIs, solving some of the challenges that crop up there. Then they expand to external partners and finally they make the jump to public APIs after they have figured out the process internally.

So, with all this knowledge its about time you get RESTed and start your own valuable corporate API programs.