What drives this? Value. APIs are the foundation of the digital economy. They're the glue that holds the cloud together and the conduit that connects your company with the rest of the world. The few lines of code that comprise an API are the window into a business. They create bridges between you and your partners, including your customers and millions of developers, whether your business uses mobile devices, the Internet of Things (IoT), the cloud or SaaS. 

Before opening up your business with APIs, you need to answer four fundamental strategic questions:

As with any strategic business initiative, you need a clear understanding of why you're embarking on this journey. Nearly all other subsequent decisions are impacted by this answer, starting with "Who is this for?", which impacts the "What is my business model?" strategy and drives the key performance indicators (KPIs) that help you track "How do I measure success?".

Keep in mind that creating a successful API program requires executive support, as well as a hard investment of dollars and resources. Since the success or failure of many organization's ultimate API program hinges on managing these internal factors, having adequately answered the "Why" question gets you started on the right foot.

What are examples that drive companies to engage in API efforts? They enable partner opportunities, create new marketing channels, increase product reach or footprint, drive traffic, increase stickiness to the core service, extend product(s), accelerate internal projects, content acquisition, support different smart devices, enable new lines of business, acquire new users, upsell opportunity, or generate leads. The list is longer, but as you can see, there's a wide array of strategic drivers behind creating a platform for your company. 

In many cases, especially in existing traditional businesses, the answer to the "Why" question is a key component of a broader digital transformation effort. APIs and platforms are often an important part of your company's key technology efforts, whether through digital transformation, mobile enablement, big data pipelines or a nascent IoT plan.

There are three classic ways that we can expose APIs in today's market: internal use cases for our own company, external use cases for our partners, and external use cases for everyone else, which is also the "open API". Even though we don't have to be exclusive, we should think about the answer holistically.

Netflix, for example, has become a poster child for a successful API strategy. In order to reach the widest possible market, Netflix needs to support movie delivery to thousands of different types of devices ranging from gaming consoles to mobile phones. How do they achieve this? Via their API platform. It's the answer to the "why" question above. Nearly every consumer interaction with the Netflix service passes through their APIs, and their APIs handle billions of API calls per day (and of course, all this API business is invisible to consumers). 

Netflix's API is for Netflix. It's an internal use case rather than an open API designed for third-party developers. The lesson here is not to assume that an API has to be for third-party developers and to think carefully about who will use your API because the answer may surprise you.

We heard from thousands of API providers over the course of a decade at ProgrammableWeb. There were a lot of questions, especially from those just beginning their API journey. How should I design my API? How do we attract developers? Should we use REST or SOAP, or XML or JSON? These are just a few of the questions, and in the end, the most persistent questions were about API business models. How do I monetize my API? Do I need to give away the farm? What is everyone else in our industry doing? How do I measure the ROI of my API?

Not surprisingly, the answers to these questions vary widely. While an answer of "It depends" is not too far off the mark, there are patterns when you look across the landscape of the thousands of APIs that exist. A useful framework is to classify them across four API business model types: free, developer pays, developer gets paid and internal use cases. The vast majority of APIs fall into one or more of these buckets. 

In the early days of web APIs, many had falsely assumed that all APIs were free. Widespread press coverage of early APIs, such as the original Twitter API, the Google Maps APIs and Facebook's APIs, fed into this belief. While some APIs are free to use, this is more the exception than the rule. Savvy API providers are capitalizing on other business models.

For example, Salesforce has such a successful API program that over half of all transactions processed by Salesforce come via their API rather than their web app. They have thousands of developers on their platform, yet they don't directly charge for API access. Why? Because they make money selling per seat SaaS subscriptions across multiple pricing tiers. Customers only have full access to their API when they subscribe to the more expensive Enterprise pricing tier, not the lower priced tiers. This indirect monetization model nicely aligns their API strategy with their overall business strategy. 

On the other hand, some APIs pay the developer to use them. While this idea can seem counterintuitive at first, it can be a great choice in some contexts. Take, for example, affiliate marketing and online advertising. Both of these markets have well-established revenue models that involve incentives like commissions and revenue sharing. 

Many companies in these markets have extended these models to their APIs. If a developer uses an e-commerce API, like that for eBay or Shopping.com, and builds a mobile price comparison app, they can use those APIs to earn revenue via click through CPC (cost per click) or CPA (cost per action). This model is a win-win for the developer and the API provider. A number of e-commerce companies do a revenue share so third-party developers receive a commission, like a fraction of a penny or between 3% and 5% of a sale, for every customer the developer sends to the site. It's profit sharing, and the third party developer is helping drive sales for those e-commerce sites.

There are a few misperceptions with the long tail and the open API though. One is you have to go all-in and begin your API journey with a fully open API. In many ways, the inverse is true. Valuing and vetting your API is easier with your own cases or a limited set of partners before opening your API to many partners. There are a number of benefits to this method, like getting validation sooner rather than later.

When most companies list the assets they might expose through an API, they think critically about which will give the highest insight and value quickly -- APIs don't come for free. It's an investment, and someone needs to make the case about value and demonstrate learnings and success. You need to think about what you're opening up and what you want to achieve.

As an example, how eBay chose which API to open in their early days might seem counterintuitive. You would think that their earliest APIs would be focused on product search and purchase, but instead, one of the earliest key APIs for eBay enabled adding products to the marketplace. That was when there was a rise of PowerSellers, and these sellers needed PowerSeller tools to let them push more product onto the marketplace. eBay wanted to open the inbound floodgate because it's often he who has the largest marketplace wins. That meant opening up more APIs for sellers rather than buyers.

Another example is Amazon. When they launched their e-commerce API a decade ago, they didn't need to invent a new business model. Why? Because they already had a successful third-party affiliate program with a proven revenue model. Rather than devise a whole new business model for their API, they just leveraged an existing affiliate model that enabled developers to share in the profits when their apps drive customers to Amazon.

If you have an API, how will you know it's succeeding unless you measure it with a business metric? There are key metrics in different categories to choose from and the "why" question drives what KPIs you choose to measure. 

Thinking about having different role-based "lenses" through which to measure your API's KPIs is helpful. A "CFO lens" focuses on financial metrics: direct and indirect revenue, CapEx and OpEx investment, and churn, for example. A "DevOps lens" focuses on operational metrics, such as performance, availability and error rates. A "CMO lens" looks at your incoming developer acquisition cost, evangelism metrics, developer portal visitor counts and anything that builds your incoming developer funnel. You don't want to go too far because having too many metrics can be just as bad as having none. 

Also keep in mind that because APIs represent a material investment of time and resources, you should think about having multiple ROIs on your investment. Opening your API for third parties and partners will help you to leverage that API for your internal projects as well. This enables not just direct revenue, but other important internal metrics, such as speed to delivery and cost reduction, in the right scenario.

There are different ways to think of a KPI. The KPI for Google Maps was designed to expand market share at first, and one of the ways they achieved this was by opening up an API to make their maps embeddable and programmable. Hundreds of thousands of websites now embed Google Maps in their sites, and the API helped Google disrupt the online mapping market and become a leader.

APIs create value for companies. If you think about the external API, Twilio had one of the most successful IPOs in 2016 and one of the first companies to have an API as a product. It wasn't the API providing a bridge to something else, but the entire business existed for the purpose of selling an API. It's a very disruptive business model. They did a phenomenal job of targeting developers and growing the business with an API as product as the core of the business.

In the last five years, many more companies have come to market where the API isn't something that exists on another product, but the API is the product. There are many different categories, and we're seeing these companies appear where the API is the thing.

APIs represent change, and change is rarely easy in any established company. Long-term success often hinges on short-term success and being able to demonstrate value. There's always a learning process from the business to technology side, and today's model is about going where the customers are -- that's what APIs enable you to do.

If you can answer the four strategic questions outlined here, then you're well on your way to having a successful API journey. Knowing the why, who, what and how will give you a solid foundation for an API strategy, and carefully developing a marketing plan to attract developers will help you be successful.