fbpx

You are viewing our site as a Broker, Switch Your View:

Agent | Broker     Reset Filters to Default     Back to List

What is the Business Value of an API?

February 03 2011

data wordGuest contributor Peter Goldey says:

I had the privilege to present on a Tech Connect panel during Inman NYC, moderated by Dan Woolley (W&R Studios).  Dan carved the conversation into three parts:  the history of API’s, covered by Adam DuVander of Programmable Web; technology tips and tricks, presented by Andrew Mattie of Diverse Solutions; and the business value of API’s – my part.

As an information services provider, Onboard Informatics is constantly looking at new sources (input) and new delivery mechanisms (output) that can benefit our clients. As Onboard’s CIO, a part of my role is to ensure that how we access and deliver content meet not only our technical requirements but also our business objectives. API’s provide an important component of our strategy to do so.

There are two sides to the coin of business value here:  Why choose to publish via API? And why choose to consume via API?

An API is an electronic exchange of value between two entities. When the business value to the publisher and consumer match – when business value is aligned – great things can happen and both business’s objectives can be met.  When the value is either unknown or out of balance, both sides must evaluate whether the relationship will work.

After the session, the questions from the audience focused squarely on the business implications of consuming and delivering content via API to the marketplace, so I must have struck a chord. API’s provide a valuable means of exchanging services and data without requiring both parties to invest in the content, data management and technology needed to deliver the content. Instead, one party – hopefully the one with a business interest and requisite expertise – can focus on how to deliver the content. The other party – the API consumer – is left to focus on their business (typically selling something or creating UI / UX for the purpose of selling something – such as a home).  The extent to which the content enables the sale establishes an exchange of value to the API consumer.


The focus of my Tech Connect presentation was what the API provider gets in exchange for this value. There is a notion in the marketplace that many API’s are “free”. Well, here’s something to think about:  if they were really free (the provider receives no value in exchange for providing API access) then there would be no API’s other than those powered by not-for-profit organizations. As Adam presented, there are literally thousands of API’s published by for profit companies.

So what do API providers receive in exchange? And, if you are thinking about producing your own API, what business drivers should be behind that effort? It is our position that there are three fundamental reasons that API’s are produced by one company to be consumed by another:

  • To generate traffic
  • To build brand recognition
  • To generate direct revenue

onboard informatics graph1

Companies may combine these drivers in their API strategy.  Each has benefits and disadvantages for the API consumer.


Traffic-Generating API’s (or Traffic Pushers)

When an API is focused on taking traffic from the consuming website and transferring it to the API provider’s website, the provider will typically focus on cost to the consumer (none) and features for the end user (slick UI).  The goal is to have an innocuous and seemingly valuable offering (perhaps providing contextual information) with the sole purpose of enticing end users to click through to the API provider’s website. Thus, the API is a marketing and customer acquisition investment by the API provider.

A variant of the traffic generator are API’s which are used to submit content to the publisher.  For example, Yelp!, Twitter and others are very happy when you provide your end users with an interface that submits reviews and updates to their accounts.  Much of the value in these companies is the content that users submit to them. So you are sending them traffic in the form of content submission and in exchange you get a cool feature and some leverage from the publisher’s brand recognition (if you need it).

  • Key Question: Is the provider’s business aligned with yours or competitive with yours?  (If you are in the business of selling homes, why would you consider sending the user to another site that is pushing the same product?)

Brand Builder API’s

These are API’s designed to build brand awareness and are also typically free of charge.  However, the display requirements imposed by the API provider are generally heavy on brand visuals such as logos and very strict in terms of presentation and placement.  The provider’s goal here is establishing consumer brand recognition through consistent and widespread visualization of their brand to the marketplace. As a result, there is generally little ability to differentiate one implementation of the API from another.  Typically, the API provider is looking to establish themselves as the definitive expert / source of the content and is taking advantage of the marketing dollars the API consumer has spent in attracting eyeballs to their website.  A good example of such an API in RE is Walkscore.  Another is the New York Times real estate market summary API.

  • Key Questions: Does the provider’s brand compete with yours and does the content, when combined with the brand display requirements, detract from your own brand and message to consumers?  Given the ready availability of the free brand and traffic API’s to your competitors in the marketplace, does integrating this content provide any differentiation for your business?

These first two API value models have both good and bad points.  On the plus side, fixed costs are low for the API consumer (no licensing / usage fees) and some great contextual content and features are available in these categories.  On the minus side is the very real possibility that the API publisher’s and your business goals are in conflict (lack of alignment). Another note here is that when things are free, there is typically little if any support, focus on data quality / accuracy, SLA, sharing of usage metrics, or implementation assistance.  All of these require resources ($$$) from the API publisher.  There is also the real risk that the API will switch to a paid model or even disappear entirely. About 40% of the API’s I’ve tracked over the last 5+ years in the industry no longer exist.

What is your standard for reliability? What is your standard for quality?


Commercial API’s

These are typically the easiest to establish a value equation for.  The majority of Onboard’s API’s are in this category.  We charge for service – typically either by usage or a fixed tiered cost.  This is precisely how Bing! and Google Maps API’s are licensed.  In exchange for $$’s, we provide reliability (SLA), performance, support, documentation, integration assistance, usage reporting, updates and all the related services you would expect from a top tier provider.  By making the API delivery itself = much (if not all) of the business value for the provider and establishing a reasonable price (approximately equal to the value to the API consumer’s business), the equation is very straight forward.  Because value to the provider is defined by agreement, the provider is able to commit to providing business value in return.  It is only when the business value to the consumer falls below the cost to deliver and service by the provider that this arrangement begins to “leak” and the provider must either lower its price or allow consumers to walk.

  • Key Questions: As a consumer, can you define the value of the content + service (support, updates, metrics, etc.) of a content API to your business?  If you can, and that value is greater than the API usage fees, then revenue driven API’s are likely to provide a reliable content or feature building block – or even foundation – for your business. If you can’t define this value, it’s impossible to establish the business value of the API.

This article was written by guest contributor Peter Goldey, from Onboard Informatics.

To learn more about Onboard Informatics, please click here.

RET-Read-More-Articles-button-150px