What data and services should your API expose first?

For some businesses, the ideal decision for them is to open data and services that help them integrate with their existing business partners first. For example, a manufacturer or retail wholesaler may share its product catalogue and inventory data via API with resellers who want to integrate updated information about available products for sale on their own retail websites. Hospitality businesses like hotel and travel accommodation, parking garages, and restaurants may have a network of online travel agents that need integrations so their customers can book directly.

When starting with a partner API approach, the goal is not to monetize the API directly (although in the future, offering a partner API more widely as a paid product may be possible). The business model for a partner API is more often about reducing integration costs and strengthening the partner relationship so they are sharing more customers with you.

"It is an indirect business model," says James Higginbotham, author of A Practical Approach to API Design and founder of the API consultancy LaunchAny . "For example, partner APIs help reduce support costs and eliminate the one-off integration cost to partners. You can then productize that partner integration to support multiple vendors. You can offer easy 'getting started' guides. Often, external partners lose their appetite for partnership opportunities because the cost to integrate is so painful, so APIs turn that around."

Another way to start an API strategy while also building internal awareness of the value of APIs is by using external APIs and then iterating on top of that. For example, before a bank even starts thinking about its own APIs, it may integrate the Google Maps API on its website to show its branch and ATM locations easily. A mindset is created. The bank may now consider making its branch and ATM location data available as an API, and then start making its product catalog available as an API.

Internal API champions may be looking for an easy way to demonstrate the advantage of APIs. They can go to individual business units and document a process that involves duplication, requires the manual re-entry of data, or requires creating a CSV file. This could be the ideal starting point for identifying how to exploit external APIs.

Consider business units that are using multiple SaaS products; they can integrate two SaaS products so that CSVs are not required in order to move data between the two sources. Occasionally, business units prepare reports manually for mailouts to a group of customers. With an external API like SendGrid for programmatically integrating with a system that's capable of mass email, they can automate these mailouts directly. Now the API champion can calculate the amount of time saved each week through automation and add the savings generated from time saved, fixing errors, or any savings from email instead of postal mailouts. To do so, document all the cost savings in an average week and multiply by 52. Subtract this from any estimations of transaction or third-party API subscription costs to show how much the business unit can save by using readily available APIs.

Often the starting point for a company's API strategy is made as part of a decision to modernize its IT architecture. For example, perhaps a business was burnt by the one-off development costs associated with their first mobile app, and it wants to create reusable components so it can build future apps using the same core set of APIs. Perhaps the company is in the process of breaking down its monolithic code base into a series of microservices, each of which gets its own API. An established business may be looking to APIs as a means to compete more effectively against new competitors that are more agile at responding to shifting market conditions. All of these so-called "digital transformation" (sometimes referred to as "business transformation") drivers lead to starting with private APIs. If the company follows API-first design principles (I'll discuss this in part 6 of this series), it also preserves the option of opening up those private APIs to partners or externally as public APIs.

While partner and internal APIs are a more common starting point for businesses, some organizations are keen to embrace a platform business model where they are modularizing their data and assets as akin to raw products. In this scenario, these businesses want external developers to build new products and services using their data and assets. For example, Walgreens had a network of photo printing machines at many of their stores. To boost these assets' revenue, they opened up the Walgreens Photo Prints API, allowing developers to integrate their image manipulation apps directly with Walgreens's printing services. This had a multiplier effect for Walgreens in three specific ways:

• External developers who were offering image apps could let customers print to a Walgreens location directly and pay for their printing within the app, generating a new customer market and revenue stream for Walgreens.
• Those app customers were more likely to make other purchases at Walgreens when they came in to collect their photos.
• The success of the approach led Walgreens to consider other API-centered opportunities.

Marc MacLeod, founder and CEO of Stoplight.io , a company specializing in API lifecycle tools, says the demand for a mobile app often drives the creation of internal APIs. Internal APIs are the best way to create mobile apps as they create reusable components that can speed up later product development. For example, if internal APIs are created to build an iOS app, those same APIs can drive functionality for an Android or wearable app in future, rather than require full product development for each new app. For partner APIs, MacLeod says speaking with the partners first to see which products or features partners want programmatically is an essential step. MacLeod cautions that public APIs can be a riskier starting point. "With public APIs, it is much more difficult to make breaking changes, so you need to be very confident in your [API's] design," he says. If API development is new to the organization, starting with external APIs to expose developers to the best practices of other API providers and then opening internal or partner APIs with a very specific dataset or service functionality may be the best route.

Jérôme Louvel, founder, CTO and VP of Products of Restlet, says that identifying who will be using the APIs is the best place to start. "Clarify the user persona and some use cases," Louvel says. This will help help determine "the context, the domain of API, and whether there will be multiple APIs that will connect closely, like in a microservices context." By starting with a clear understanding of the API consumer, a business can map which APIs to make available initially and identify what information, services, and data stores to open.

David Chao, head of Industry Marketing at MuleSoft (the parent company of ProgrammableWeb) says that identifying what data or services should be made available via an API may require some introductory API sessions with business leaders to help them understand the role of APIs in driving transformation and connectivity to backend systems. "More and more, we are seeing that organizations intrinsically get this: They understand why APIs are important. Business strategy and tech strategy are really merging, so that means working with our partners to understand their business goals and what technologies they need to get them there as well as any connectivity requirements."

"Companies should make decisions around building internal support while thinking about the team that will lead an API first," says Chao. "It is not about one-off tech solutions but about people and processes."

"Ask what is the broad set of APIs I need to have, regardless of whether the APIs are internal or external," he says. Think beyond internal and external first because you do not need to be pre-emptively constrained by these limitations. For example, consider a bank that opened up one of its internally focused payments services as an external API. "Now, when a corporate account wants to make a payment through a supplier, instead of having to do it through the bank's account manager or online, [its] customers can access those services directly through the API rather than going through a call center. Now it is the same payment API that is triggered through the call center and its Web app, and at same time [it has] increased customer direct access through the API."

Governments around the world are often working with open data portals like the open source CKAN and the proprietary offerings of OpenDataSoft and Socrata to make government and city data available to local businesses, community groups, and citizens. These three portals all have automatic API generation tools that allow users to access the datasets available in the portal via the portal's API. However, these are often limited in their functionality and have highly prescriptive limits on use. They are intended for the assessment of the dataset more than production use or integration to the data on an ongoing basis. There are limited signs of any uptake of the use of these APIs globally.

Meanwhile, those national and state governments and cities making their data and services open via API are progressing slowly. The best examples are in the United Kingdom , where their tax department has made APIs available, making the direct integration of accounting software possible. Visitors can now enter their financial data, which is always in alignment with tax regulations, simplifying tax lodgement. The U.K.'s Ministry of Justice also includes APIs to assist families and individuals entering the court system with less stress and confusion.

In the U.S., the Federal General Services Administration has a branch called 18F, which encourages government agencies to use APIs to provide data access to services. These include which small businesses are available for contracting for projects, freedom of information request services, and platform service APIs to help agencies manage the creation and delivery of Web services. Other examples include:

• The National Aeronautics and Space Administration (NASA), which has released a number of APIs, including for images from the Hubble space telescope, satellite imagery, and data from funded research.
• The U.S Recreation Information Database, which catalogs all parklands, trails, and other information and exposes it via API for use in environmental and recreational applications.
• The U.S. Energy Information Agency, which not only creates APIs, but also built tools like Google Sheets and chart and map visualizations, allowing nontechnical users to consume the APIs.
• The GSA's Digital Registry, which maintains a list of all social media accounts operated across all Government agencies.
• The OpenFDA, which provides data on drug enforcement reports, adverse reactions to medications, and updates on medical devices via API for integration into health-related apps and services.

In Australia, work on encouraging APIs in national service delivery may have stalled again because key champions working in the Federal Digital Transformation Office have left the agency .

At a city level, APIs are still not used extensively to provide service access or data use. Some limited examples exist particularly around transport data and waste management data. The most advanced use case within cities is often open311 , an API-based system for citizens to lodge complaints about potholes, graffiti, or other issues. That data is then anonymized and made available in real time via API; however, there are few instances showing how people are using that data. A simple use case of calling the open311 API to map whether complaint responses are responded to equally in high-income neighborhoods as well as in low-income neighborhoods is still unavailable anywhere in the world. Some people are even questioning whether responses to 311 calls are widening inequalities in some cities.

At the MuleSoft Summit in London in October 2016, Sarvesh Jagannivas, VP of Product Marketing at MuleSoft, described how Coca Cola began thinking about its API strategy and what data to open up first.

The company started by thinking about its business objectives. It wanted to improve customer engagement, ensure sales effectiveness, and encourage maintenance of global standards. For example, when one of Coca Cola's bottling suppliers discovers an efficiency in its plant operations, the supplier wants a way to make the steps of that newly efficient process available internationally to the other bottling suppliers who have partnerships with the supplier.

To do this, Coca Cola mapped its systems and identified how it could organize its APIs into three layers:

• At the base, the company would have system APIs, such as customer and shipment data.
• Above this was a layer of process APIs, such as APIs for sales, purchasing and ordering, and shipment status. These would connect with customer or shipment data in the system API layer when transactions occurred.
• At the top layer are experience APIs, which are often tightly coupled to an application, Web, or mobile app for creating a specific customer experience.

By thinking through this model, Coca Cola was able to start working on its API strategy methodically in a systems approach that was also more stable and timely. The base level system APIs are often tied to slower changing data assets that could be updated via batches, while process APIs might require real-time processing. The company can invoke experience APIs as needed in a user application session and may be seasonal or customer segment-limited.

Now that you have begun making decisions about which data and services to consider opening up via APIs, you now need to look at how to build a business model around your API strategy. See our next chapter to answer, What is My API Business Model?