Multi Tenant API Management with WSO2 API Manager - Part 1


WSO2 API Manager provides a complete solution for API Management. With Multi-tenancy in WSO2 API Manager, organizations can collaborate and monetize their APIs across multiple entities such as departments, partners or simply between separate development groups. 

Why Multi-Tenancy

The goal of Multi Tenancy is, maximizing resource sharing among multiple tenants while providing an isolated view for each tenant.

One of the main benefits of multi-tenancy is the ability to use a single deployment for multiple tenants which lowers the cost and provides better administration. Further this is ideal for  multi departmental and multi-partner type of business settings.

Multi-Tenancy in API Development

WSO2 API Manager provides a simplified Web interface called WSO2 API Publisher for API Design, Implementation and Management. It is a structured GUI designed for API creators to design, implement, manage, document, scale and version APIs, while also facilitating more API management-related tasks such as life-cycle management, monetization, analyzing statistics, quality & usage and promoting & encouraging potential consumers & partners to adopt the API in their solutions.

While providing all these capabilities, WSO2 API Publisher is a tenant isolated application. Meaning, developers from different tenant domains can develop APIs and manage them while having isolated views for each tenant. Let’s look into more details by using a example scenario. 

Example : There is a multi departmental organization in which 3 departments namely HR, Sales and Engineering need to expose their core functionality/services as APIs to internal and external consumption. They are using WSO2 API Manager as the API management solution. So we can consider those 3 departments as 3 tenants in WSO2 API Manager. So that each department can develop and manage their APIs independently.

First we need to create 3 tenants in WSO2 API Manager. Please refer this doc, for tenant creation and listing steps. 

Let’s assume that following tenant domain names are used for each department.

Department Name Tenant Domain
Human Resource

Figure 1 : Tenant Isolated API Publishing for each department

Once you create the tenants, you can login to API Publisher using tenant credentials and design, implement, manage & publish APIs. Find User Guide on API development from here (

Now when tenant users of each domain will have isolated views in API Publisher as below where each tenant have their own view. 


Figure 2 : API Publisher view

Figure 3 : API Publisher view

Multi-Tenancy in API Store

API Manager provides a structured Web interface called the WSO2 API Store to host published APIs. API consumers and partners can self-register to it on-demand to find, explore and subscribe to APIs, evaluate available resources and collaboration channels. The API store is where the interaction between potential API consumers and API providers happen. Its simplified UI reduces time and effort taken when evaluating enterprise-grade, secure, protected, authenticated API resources.

When there are multiple tenants in the API Manager deployment, there is a tenant isolated view of API store for each tenant domain. In other words there will be a separate store for each tenant.

Public Store and Tenant Stores 

When API Store URL (ex: http://localhost:9443/store) is accessed in a multi tenant deployment, we can see the ‘Public Store’ which is a store of stores.
Public Store is linking to Stores  of all the tenants. For anonymous users, each of this Stores can be browsed. All the Public APIs of each Store will be visible. If one needs to subscribe to APIs, then he should log in to one of the Stores.


Figure 4 : Public Store linking all the tenant stores

Each of the Stores representing each tenant domain is known as ‘Tenant Store’. It is the tenant isolated API Store of each domain. ex: http://localhost:9443/store?

Subscribers from each tenant domain can consume APIs in their tenant store. Let’s look into more details by using an example scenario.

Example: You are a subscriber on tenant domain. You can first access the Public Store and then visit Store. Then you can log in to the store with your credentials and consume APIs. Also you can go back to the Public Store and access other Stores as well. But if you want to consume an API in other tenant stores, API developers should allow that. It will be discussed further in “Manage subscriptions among multiple tenants” section in next post. 

Figure 5 : Tenant Store

So as described above, different tenants can develop and consume APIs in isolated views of API Publisher and API Store. Next post will describe how API creators can control who can subscribe to APIs. 


  1. Hi It is interesting article but Images are missing can you please restore Thanks

  2. Hi It is interesting article but Images are missing can you please restore Thanks


Post a Comment

Popular posts from this blog

PHP-SOAP web service with out a WSDL

How to add Maven dependency from a relative path referencing a local jar

Boomi Mapping - Removing special chars from an input