Key Steps to Building and Managing an Effective API Marketplace

Across industries, companies are now looking for ways to shape their digital businesses by extending their services through external APIs. To reap the benefits of an API program, however, organizations need to move beyond basic API management to creating an API marketplace, a specialized type of platform business model that focuses on connecting producers and consumers. As more companies look toward business platforms for competitive advantage, the API marketplace brings the benefits of the platform business model to API management.

As such, an API marketplace typically addresses not only the developer portal and other technology aspects of API management, but also the business and human aspects of ensuring that APIs achieve what they were intended for in the first place: promoting the consumption and usage of APIs.

In the following sections, we will explore both the technology and business considerations that come into play in an API ecosystem and discuss the key steps to creating and managing an effective API marketplace.

API Management Anchors the API Marketplace

Generally, an API marketplace comprises several components. In a typical scenario, producers first publish APIs, and these are then catalogued and displayed via an API developer portal. This encourages consumers of the APIs to access the developer portal directly or indirectly (via system APIs for instance) to find, discover, and explore them. The developer portal displays different types of APIs, grouped by division, category, type etc. With specific APIs, users can then test and subscribe to them. How these components of an API marketplace interact is illustrated in Figure 1.

The API management system provides the anchor for any API marketplace and enables it to function effectively. It typically consists of five core components:

• An API gateway serves as the API runtime and policy enforcement point, enforcing throttling, rate limiting and security policies.
• API security may be provided at a basic level by the gateway or through an integrated identity and access management (IAM) solution.
• An API developer portal acts as a catalog and provides a centralized location for application developers to discover, subscribe to and test APIs.
• An API publishing portal provides the ability to design APIs from backend services.
• API analytics offers a snapshot of API usage and feed data for API monetization.

Successfully implementing a marketplace requires taking a more advanced approach to implementing some aspects of the API management system, most notably the API developer portal and analytics. At the same time, organizational practices will also play an important role in establishing a highly functional marketplace. Below we examine the five essential elements for building a robust community for promoting the use of APIs to build apps that aim to drive more people to the business, grow revenue streams, and increase loyalty.

Figure 1: Key components of an API marketplace

API Developer Portal

The first element is the implementation of an effective API developer portal. In an API marketplace, the developer portal has to provide an intuitive experience to support the community of developers the enterprise seeks to attract—whether professional software developers, business power users or long-tail developers. The long-tail developers referred to here are developers who are not immediately part of the API provider’s enterprise customers or partners; rather, the set of independent developers (who might be part of larger organizations and thus be potential customers) who seek API documentation to build apps around the API. The API provider can opt to host all resources and documentation behind a protected signup page or be more transparent by having these open to public. These consumers may come to the developer portal directly or indirectly (via machine to machine communication for instance) to find, discover and explore APIs. The developer portal displays different types of APIs, grouped by division, category, type, etc. Users can then test and subscribe to specific APIs.

A good example is a customer of ours, a large telecommunications service provider, that has built an API-driven application/service creation ecosystem, which fosters fast, easy creation of digital, over-the-top (OTT) services that run on the company’s mobile communications platform. Separate portals for developers and non-developers provide intuitive experiences for users to review the terms and conditions, sign up, and start engaging with the telco services in just minutes.

Services created for the platform by professional and “community” developers are published on the telco company’s app store. The tailored portal approach has enabled the business to offer apps from a broad range of developers, from start-ups to enterprises to government agencies to non-developers within small retail businesses, schools, churches and charities. In the first 18 months alone, more than 2,500 app creators published 3,300-plus applications and services based on the telco business’ APIs.

In a typical API management environment, the organization’s API owners publish a set of APIs, which are then consumed by application developers. However to make this concept truly sustainable, the application developer needs to have a say in the form and type of APIs published. This could range from a request to add a field to an API, to mashing up a number of different APIs into a new one to fit a particular device’s constraints and requirements.

The simplest way of achieving this is to have forums or ticketing systems that track feature requests and facilitate communications between the consumers and producers of APIs. A more forward-thinking approach is where the API developer portal itself allows a self-service sandbox platform for consumers to mashup APIs and create their own private APIs. The latter offers the perfect platform for consumers to create their own private APIs that cater to the application’s unique requirements, while maintaining the official APIs published by the provider,

Incentives to Promote Reuse

Beyond creating a portal, enterprises also need to incorporate incentives in the marketplace that promote API reuse. There are both monetary and non-financial incentives to drive adoption. Within organizations, the incentives typically do not have a monetary value. For example, companies may maintain a leaderboard that highlights top API publishers and application developers. Enterprises can also track which APIs have the most subscribers and display them on dashboards on the developer portal. Workshops and hackathons that allow developers to learn and apply skills can also serve as incentives.

When seeking to provide incentives to external parties, organizations more often will apply some form of financial incentive. For example, the telecommunications service provider discussed earlier allows users to rapidly create applications using pre-defined templates, and then enables them to share the revenues generated from the applications that they have published on the company’s app store. The revenue-sharing model for each service is 70% for the third-party creator of the service and 30% for the telco. This has led the business to realize a 20% month-on-month growth in revenues derived from the apps built using its APIs.

Monetizing APIs

APIs are fast becoming products that are sold or made available to application developers, generating revenues from other business units or third-party organizations that consume them. Therefore, API marketplaces require mechanisms for directly or indirectly monetizing APIs.

With indirect monetization, companies recognize that wider use of APIs brings more customers and transactions to their core business, as well as extends the ecosystem. A great example is StubHub, a leading seller of event tickets. A goal of its API program is to enable the ecosystem of travel companies, hotels, and others in the hospitality sector to upsell event tickets to their customers. Anytime a hotel customer uses the StubHub API from the hotel’s website, StubHub makes money.

Meanwhile, there are two types of direct monetization that organizations may want to employ. With direct internal monetization, one department typically bills back another for the use of particular APIs. Because funds are allocated internally by corporate accounting, there is no actual credit card charge or wire transfer. In an external direct monetization scenario, an enterprise sells a service, and customers are external businesses whose solutions are enhanced by the APIs. For example, Twilio sells APIs that let Uber offer text messaging and phone calls from within Uber’s mobile app.

Analytics play an important role in monetization, helping enterprises to understand how the program is doing, which APIs are in use, and how well the developer portal interacts with partners and manages them. Through analytics, businesses can gain insights into when API consumers are reaching the limits of their API agreements, and use the information to upsell these users to higher level plans.

Organizations implementing direct API monetization models will need to track usage on a more incremental level if the goal is to charge per-use of an API, as well as handle invoicing. Additionally, direct external monetization requires the integration of a billing engine and, most likely, a payment gateway that complies with Payment Card Industry Data Security Standard (PCI DSS). Cloud-based solutions already have PCI-compliant billing, freeing an organization from having to care about compliance or certifications. Therefore, even if most of the API management deployment is on-premises, the billing part will likely be outsourced to a cloud service.

Overarching Governance

In managing an API marketplace, enterprises need to maintain control over who can publish what and where, as well as ensure that the right APIs are published in accordance with organizational standards, such as URL patterns, naming conventions, and access control rules. To this end, they need to ensure the inclusion of an overarching governance model that helps to meet strategic and compliance requirements.

APIs can be governed centrally by publishing them in a centralized API developer portal. But to avoid stifling creativity, enterprises may want to consider a bottom-up governance strategy instead of a top-down approach. For instance, the enterprise can opt for a decentralized API publishing model, giving each business unit autonomy in designing and publishing APIs.

While the main objective is to apply structure to the management of APIs, a bottom-up approach meets this requirement by enabling each business function to independently manage its respective APIs, including updates or design enhancements to these published APIs. Breaking down this task enables each business unit to be creative in how team members build and expose their APIs while ensuring the efficient management of them.

API Analytics

As already discussed, analytics plays an important role in supporting API monetization. More broadly, API analytics offers enterprises insight into up-to-the-moment issues with performance, availability, and potential security issues, as well as analysis over time to support decision-making. Typically, organizations implementing an API marketplace will rely on a combination of analytics capabilities, which may be provided either as a complete platform or as individual products, depending on their specific requirements.

Enterprises are often most familiar with batch analytics, which can be incorporated to identify longer term trends on APIs that have been published over time. Some of these trends include faulty invocations, latency time, general usage across geo locations, signups over time, throttled out requests, abnormal response alerts, and API health availability alerts.

However, it is important to incorporate streaming analytics software, which typically also incorporates complex event processing technology, to obtain real-time insights into usage, performance, and other key metrics. Open-source options include the Esper and Siddhi CEP engines along with the Apache Storm and Apache Spark streaming analytics projects. Significantly, predictive analytics through machine-learning can be applied to a combination of real-time and historic (batch) data to identify such issues as potential fraud, subscriber rate limits, imminent capacity limits, or other factors in order to trigger timely, appropriate actions.

Finally, dashboards enable business and IT users to visualize trends from both streaming and batch analytics in a meaningful way to gain insights into the available data. Through dashboards, enterprises can track a set of common trends and then specify different alerts as required. For example, enterprises may want to track general usage of the API per application, top users who make the most API invocations per application, and the resource path used by an API per application.

Organizations may also want to use a dashboard to monitor the number of faulty API invocations per application. For instance, in a faulty invocation, the message is mediated through the fault sequence, and by default an API management system would consider an API invocation to be faulty when the backend service is unavailable. Other sample dashboards include API latency time, API usages across geo locations, developer signups over time, and abnormal response time alerts.

As with any business, success depends on contribution and participation by all stakeholders, and a working API marketplace is participatory business at its best. By incorporating the technologies and strategies discussed here, enterprises will be well positioned to build on their current API management initiatives to create API marketplaces that drive expansion, foster new business opportunities, and create new revenue streams.

About the Author

Mifan Careem is the senior director of solutions architecture at WSO2. In his role, he works closely with customers liaising with WSO2 engineering and sales teams to analyze and define domain specific solution architectures for clients’ requirements.