The 5 Types of API Marketplaces
APIs should be designed as true digital products — which are reproducible, fungible, and reliable — and not merely to expose systems. Ideally, an API should come with documentation and sample code to quickly get developers up and running even if they are new to the API. Enterprises should apply API product management to create APIs in a standard, compliant, and consistent manner. Internal API management is not only valuable for API reuse and discovery, but also to track usage of highly performing APIs and applications. Essentially, an API should represent a complete product that can be sold easily in a marketplace.
When looking at public API marketplaces, e.g., RapidAPI and IdeaBiz, we see that API usage is definitely increasing, proving that APIs are in fact the products of the 21st century.
All too often we hear the perception that an API marketplace is actually a developer portal. This is incorrect: an API marketplace differs in that it is an ecosystem of multiple components, in addition to the characteristics of a portal. Also, a marketplace comes about through API federation, which brings together APIs that are provided by multiple parties. When building an API marketplace, a developer portal becomes a key component — but one that is accessed by consumers and to which APIs are pushed by several providers. So, a single provider, a single consumer group developer portal is definitely not an API marketplace. A developer portal with many providers and consumer groups is merely part of a larger ecosystem of many other components that form an API marketplace.
Over the past 15 years, WSO2 has helped a number of enterprise customers to implement API marketplaces. During the course of our work, we have identified five main patterns. This article discusses each of these patterns by looking at the reach of each approach, the different components, the deployment models, the operational models, and examples so that you can better understand each pattern and decide which pattern would suit you best.
API Marketplace Patterns of Federation
Internal marketplace
Figure 1: Federated Internal Marketplace
This is a marketplace that is limited to a single organization. The federators or different publishers are the different teams, departments, or business units who own APIs, manage them and need to push these into a common marketplace for reuse within the organization. The consumers are the various internal units as well as external partners who may use a subset of these APIs.
Since there are different units that own these APIs, there is autonomy within a unit in how an API is defined and how it is managed. However, since it is published into a common marketplace, there will also be some amount of overall governance and quality control that would be applied when an API is being published in order to make sure that all APIs conform to a base quality level. There is no revenue incentive here for the different units—rather the main goal is reuse and collaboration. The deployment of an internal marketplace can come in two flavors.
Shared components:
In a fully shared model, as shown in Figure 2, each unit will use the shared publisher to create and publish APIs. Once published, all APIs from all units will be shown on a shared developer portal. For invocation purposes, each unit may have its own gateway to manage incoming requests. This gateway will be placed closer to the endpoints that the units own.
Figure 2: Deployment of an internal marketplace (i)
Since all units share common components of the marketplace, the underlying API management platform needs to support reliable visibility control both at the publisher and the developer portal layers so that logged-in users from a specific unit are able to see only the APIs that are relevant to them.
Separate components converging into a common marketplace portal:
Figure 3: Deployment of an internal marketplace (ii)
In the model shown in Figure 3, each unit has its own separate publisher and developer portal. So, APIs will be created on these components that are managed by the unit. However, since the overall intention of the pattern is to promote the reuse of APIs across units in an organization, there needs to be a central marketplace portal, as well as a place where the published APIs can be seen. The underlying API management platform needs to provide the capability to a) provide multiple developer portals and b) publish to multiple developer portals when an API is published from the publisher component. Again, each unit will have its own gateway to handle the API invocations.
Scania, which is a Europe-based large truck manufacturer, adopted the internal marketplace pattern. The company started off with the shared-component centralized model, where there was a center of excellence unit in the organization through which every decision was made. However, this did not work out, since the different business units that created the APIs required more autonomy. Eventually, they moved towards an internal marketplace pattern that was inclined towards the separate components converging to a common marketplace deployment model.
In most of the patterns, the conceptual model is a central marketplace and different aspects of federation are from the providers’ point of view and also takes into account how consumers use these APIs. So, in order to keep the diagrams simple, we will use the first flavor of the internal marketplace diagram to depict the concept of a common marketplace from hereon.
Partner Marketplace
Figure 4: Federated Partner Marketplace
The next marketplace pattern is the partner marketplace pattern. This is an extension of the first pattern. Still, the different internal units will publish APIs into the marketplace. In addition to the internal organizational units, partner organizations are also recognized, as, at the end of the day, partners end up being part of an overall ecosystem. Originally, partners could be part of the consumer network that use the APIs published by various internal units. However, with time, if some of these partner organizations have APIs, which will be used by the same consumers to create more value. Then, the marketplace is opened up so that these partners can also publish their APIs into the same marketplace, making these accessible to the same API consumer base.
The deployment of this marketplace can again follow the same two flavors of the internal marketplace.
Figure 5: Deployment of a partner marketplace
Similar to each unit publishing APIs into a common marketplace, the partner organization will also publish their APIs into that same common marketplace. The underlying API management platform needs to support external identities of the partner organization either through federation or through incorporating the partner user store within the deployment.
BNY Mellon, which is one of the world’s largest asset management banks, has a unified API marketplace that was accessed by internal consumer business units as well as partner consumer units. This marketplace was then opened up for these partner units to also publish their own APIs as well, thus giving a richer API collection for the overall consumer community to pick and use from within their applications.
Closed Group Marketplace
Figure 6: Federated closed group marketplace
A closed group marketplace is a marketplace that is not limited to a single organization. Instead, it is a marketplace that is common to several organizations, where these organizations are linked together with a common focus. For example, they belong to the same theme of operation, belong to the same industry, are working towards a common goal, etc. Although this is not a marketplace that is limited to a single organization, not any organization can just join. There would be some governing body that would include organizations into this group through an invite based on the commonality parameter. The federation aspect comes naturally since these are in fact distinct organizations that are converging on a common marketplace.
The deployment of a closed group marketplace can be depicted as shown in the figure below.
In this model, each organization may have its own API management infrastructure, but conceptually, they will share common components, especially when publishing to a common developer portal. Each organization will have its own gateway and also security components.
The underlying API management platform needs to support the ability to create unified APIs based on a standard specification and also be able to integrate seamlessly with external identity providers and possibly gateways.
Figure 7: Deployment of a closed group marketplace
One example of a closed group marketplace is one that Europe-based financial institutions use, as they need to adhere to a standard specification when exposing their APIs. These organizations do not work together or towards a common cause, but in fact are competitors. However, due to regulatory requirements, they need to expose their internal operations in a standard way so that third-party providers can consume these APIs in a standard manner when creating aggregator applications and payment applications. The consumers are the beneficiaries of this and so are the end-users since they now can access all their financial resources through a single application.
Another example of a closed group marketplace is a government marketplace, where the commonality factor is working towards a shared goal. A government can have multiple agencies under it, but all the services provided by these ministries should be along the same theme that is set by the government. This marketplace will host all APIs from various such agencies so that API consumers can access these at a single place. Smart Dubai is such an example, where while preserving the independence of the different government departments, the government was still able to provide a unified API marketplace that provided digital services of various departments in a single place.
Shared Revenue Marketplace
Figure 8: Federated shared revenue marketplace
A shared revenue marketplace is an API marketplace that is open to anyone who wants to host their APIs on a known platform. There is no restriction similar to that seen in the closed group pattern except that the governing body may need to run some base validity checks before an organization joins this marketplace and starts publishing APIs on it. The main driver behind this pattern is the sharing of revenue across the stakeholders. The marketplace provider shares revenue with the providers of the APIs. The APIs that are hosted in this marketplace can be monetized either directly or indirectly.
Deployment of a shared revenue marketplace:
Figure 9: Deployment of a shared revenue marketplace with a common GW technology
In a shared revenue marketplace, different organizations will host their APIs on a single platform. They will share the common publisher and developer portal of the marketplace. In some cases, they will use the gateway functionality provided by the marketplace itself where each organization would get a separate gateway or gateway space, as shown in Figure 9. In other cases, some marketplaces, which are gateway agnostic, may provide the capability for these different organizations to integrate their own gateways into the marketplace infrastructure, as shown in Figure 10.
A good example of a shared revenue marketplace is RapidAPI, which is one of the leading marketplaces globally. RapidAPI to date hosts 20,000 APIs, experiencing over a trillion API calls. They have different flavors of marketplaces, as a public marketplace and also as teams and enterprise hubs, which are more in line with private marketplaces focusing on a few organizations.
Ideabiz is yet another example. This was an initiative of Dialog Axiata, a mobile operator in Sri Lanka. It started off as an internal marketplace and today is a public marketplace where 2,500 developers were able to produce 3,000 applications in just 18 months after inception.
Figure 10: Deployment of a shared revenue marketplace that is GW agnosticzzXAzZ
Aggregator Marketplace
Figure 11: Federated aggregator marketplace
An aggregator marketplace is where API providers provide APIs to a platform. Then, these APIs or parts of these APIs are taken and made into products that are considered to be value bundles and sold. The components of a single product that is sold can come from different parties. So, revenue is shared but in a staggered manner. The consumers of the hub pay for the API products they consume from the hub. The hub owner retains some of this revenue and then distributes the rest amongst the various providers who provided the building blocks for the products which were sold.
Deployment of an aggregator marketplace:
The deployment model of this marketplace would be as shown in Figure 12. Each organization that contributes or provides APIs to the marketplace will have its own publisher, developer portal, and gateway. Some of these APIs will be considered as those fit to be on the aggregator marketplace as well. The aggregator marketplace will also have its own publisher since the aggregation needs to happen there. An aggregator marketplace can consist of at least one hub. The API providers will create their APIs on the hub publisher through a valid definition and then at the hub publisher, an API product is created through mashing up several such APIs or resources from several such APIs.
Figure 12: Deployment of an aggregator marketplace with a single hub
These API products are published from the hub publisher to the hub developer portal. The hub will have its own consumer bases who would subscribe to these API products and consume the APIs. The hub will also have its own gateway.
An extension to the above pattern would be where there are multiple such hubs, as shown in Figure 13. Hub 1 would then provide some of the API products to hub 2, which would also have its own set of API providers and its own collection of API products as well. The API products that were shared from hub 1 to hub 2 would gain revenue at hub 2 and hub 1.
An example of this is Apigate, which follows this pattern in the telecom space. Apigate created an API hub in southeast Asia to aggregate and sell APIs to telecom operators in the region. The telecom operator pays for the API products they use and Apigate redistributes this revenue amongst the API providers after keeping a percentage. They have also expanded by reselling to a second such hub in the Middle East, thus sharing revenue across multiple hubs.
Figure 13: Deployment of an aggregator marketplace with multiple hubs
API Marketplace Patterns of Deployment
All the above patterns are patterns of marketplaces that came through from the federation of APIs. The classification occurred through observing and making note of how each one of these was distinct from the others based on factors such as who owned the APIs.
We can also come up with a set of patterns of marketplaces that are based on how the marketplaces are deployed. We would like to briefly touch upon that in the next section before we end this write up so that in the future, we will have API marketplaces categorized not only through patterns of federation but also through patterns of deployment.
Shared component marketplace
Figure 14: Shared component marketplace
All components are shared amongst all units that use the marketplace.
Shared publisher and portal component marketplace
Figure 15: Partially shared component marketplace
Each unit that uses the marketplace has its own publisher and developer portal; they also publish APIs into a central marketplace portal. Additionally, each unit has its own gateway as well, which may be placed closer to the endpoints that the unit owns.
Shared publisher and portal component marketplace, which is GW agnostic
Figure 16: GW agnostic shared component marketplace
The marketplace provides a shared publisher and developer portal, and, by default, provides a gateway. It also provides the ability for each API provider to bring in their own gateway and overall runtime infrastructure. This requires the underlying API management platform to be able to integrate with multiple gateways as well as the developer portal component of the marketplace to integrate with multiple API security providers. This pattern enables an organization to not only have its own enterprise API deployment but also expose their APIs in an external marketplace, while not changing any of the runtime components.
Hub marketplace model
Figure 17: Single hub model
In the hub model, the hub operator has an API publisher and a developer portal together with a gateway. API providers create APIs and publish these on their own developer portals and have their own subscriber base. Some of these APIs are deemed to be valuable as part of a bundle for the hub owner who creates API products from multiple APIs. These APIs are created on the hub publisher and then the value bundle products are created off several such APIs on the hub publisher and published onto the hub developer portal. It is not necessary to publish the individual APIs to the hub developer portal since these will not be subscribed to. Various entities will buy these value bundles off the hub and these value bundles will be used by the consumer bases of these entities.
An extension of this is the multiple hub model, which is shown in Figure 18. In this case, there are multiple hubs and some of the API value bundles are shared in other hubs as well and sold to newer entities with new consumer bases. Also, with multiple hubs, more API providers will connect to the additional hubs and provide APIs that can be bundled into value products.
Figure 18: Multiple hub model
Conclusion
API marketplaces are important in today’s world, and it is important to note how they differ from typical, physical marketplaces. A marketplace provider needs to remember that users, i.e., API providers and consumers, will still value the buying and selling experience, with benefits to make it API specific.
Similar to all things being used repeatedly, API marketplaces also can be categorized into patterns. When building an enterprise API marketplace, or when wanting to be part of an API marketplace, it is important to understand the specific features of each so that you get to know which marketplace pattern fits your needs best.
An API marketplace’s influence on the enterprise computing space goes beyond the technical aspect, i.e., the transition from a company’s API portal to that of a shared environment where many publishers and organizations list their APIs. It combines technology with the business and human aspects to promote the use and consumption of APIs. Not only does an API marketplace create a richer environment and a more interesting space for us to work in, but it also fosters the growth of federated APIs across external and internal ecosystems.