Connect API Portal to multiple API Managers

This topic describes how to configure API Portal to connect to more than one API Managers:

Example architectures

APIs are often hosted in several API Manager instances, for example, in multiple environments (sandbox, testing, production) or in multiple API Catalogs (like for internal users and for external users). Instead of linking API Portal to just one API Manager, you can configure API Portal to connect to multiple API Managers so that the exposed APIs can be explored centrally in one place.

For example, you can configure API Portal as a centralized catalog presenting API across all environments:

Illustration on how API Portal centralizes APIs from multiple environments

This type of portal is recommended only for internal purposes and internal users.

Alternatively, API Portal can pull APIs from different deployments. For example, you could host one API Manager with non-business critical APIs in a cloud, and another API Manager containing the APIs on confidential data on-premise. A single API Portal can connect to both deployments, and expose the APIs as configured in each API Manager:

Illustration showing API Portal exposing APIs from both cloud and on-premise deployments.

Data synchronization

API Managers and API Catalogs are configured normally, each API Manager controlling how the APIs in it are exposed.

One of the API Managers is assigned as a master API Manager, and it controls all user operations, such as signing up and signing in to API Portal, forgotten password, and updates to user profiles. The rest of the API Managers act as slaves that automatically upon user login call the master API Managerusing a specific policy for the user information, and then replicate the user and create API Portal user session cookies.

Other operations in API Portal, such as managing organizations, APIs, and applications, are done separately for each API Manager as per usual.

For better performance, you can configure the APIs from all API Managers to be cached in a Redis cache. Instead of directly querying each API Manager separately, API Portal reads APIs from the cache. This improves the performance especially when there are great number of APIs.

Example login flow with multiple API Managers

  1. A user tries to log in to API Portal.
  2. API Portal sends a login request including the login credentials to all API Managers.
  3. API Manager finds the user in its user registry, and allows the user to log in.
  4. If a slave API Manager does not find the user, it triggers a specific policy that calls to the master API Manager to query for the user.
  5. If the master API Manager finds the user, it returns all the user parameters (name, email, organization) to the slave API Manager.
  6. The slave API Manager creates a session cookie for the user and returns that to API Portal along with the user's organization and APIs and applications in it.
  7. The user is logged in to API Portal .
  8. When the user is logged out, the session is destroyed on the slave API Managers.

After a successful login, the user can see APIs and applications assigned to the user's organization in all API Manager instances. For example, the user A belongs to organization X that has the following configurations on two API Managers:

Master API Manager Slave API Manager
  • Organization X has application F that is shared with the user A.
  • Organization X has APIs C and D that are both assigned to application F.
  • Organization X has application Q that is shared with the user A.
  • Organization X has APIs G and H that are both assigned to application Q.

This means that when API Portal is connected to both API Managers, the user A sees the APIs C, D, G, and H listed in API Catalog, and applications F and Q on the Applications page. If API Portal was only connected to, say, master API Manager, the user A would see only APIs C and D, and application F.


Before you start, you must have the following:

  • All the API Manager instances are configured and running.
  • All the organizations are created on all API Managers. Ensure that the name of an organization is identical across all instances.
  • Users are created and assigned to organizations on the master API Manager.

For more details on installing and configuring API Manager, see the API Gateway Installation Guide and API Manager User Guide.

For better performance, it is recommended to use a Redis cache. For more details, see Install API Portal.

Configure synchronization policies for API Managers

The slave API Managers communicate with the master API Manager using an external identity provider policy. A sample policy container and policies are available as a separate download package from Axway Support at The sample policy package includes two sample policies:

  • AuthoToMasterDynamicOrg.xml – Use this policy if you are connecting to API Manager 7.5.3 up to and including Service Pack 6.
  • AuthoToMasterDynamicOrg_ApiManager_753_SP7_or_later.xml – Use this policy if you are connecting to API Manager 7.5.3 with Service Pack 7 or later.

You must import the policy container to Policy Studio, configure the sample policies to point to your master API Manager, configure your environment settings, and deploy the configuration to your slave API Manager. For more information on working in Policy Studio, see API Gateway Policy Developer Guide.

Note   You must create a separate project for each slave API Manager to use separate connections when deploying the configured policy.

Import and configure the policies

  1. In Policy Studio, create a new project from the API Gateway instance running the slave API Manager you want to configure.
  2. Click File > Import > Import Configuration Fragment, and import the appropriate sample policy (AuthoToMasterDynamicOrg.xml or AuthoToMasterDynamicOrg_ApiManager_753_SP7_or_later.xml).
  3. In the Policy Studio node tree, click Policies > Sample policies > AuthoToMaster, and open the policy AuthenticateToMaster.
  4. Double-click the Login to Master routing filter, and change the IP address and port in URL to point to your master API Manager.
  5. On the Settings tab, under Redirect, ensure that Follow redirects is not selected and click Finish.
  6. Open the policy Get Current Info, and repeat steps 4 and 5 on the get current info routing filter.
  7. Open the policy GetOrganizationName, and repeat steps 4 and 5 on the get organization name routing filter.

Configure environment settings

  1. In the Policy Studio node tree, click Environment Configuration > Listeners > API Gateway > API Portal > Ports.
  2. Open the configured port, go to the Mutual Authentication tab, and check that Ignore client certificates is selected.
  3. In the node tree, click Environment Configuration > Listeners > API Gateway > API Portal > Paths, and under /api/portal/, double-click API Manager API v1.2, and click Add.
  4. Add a new servlet property:
    • Name: CsrfProtectionFilterFactory.refererWhitelist
    • Value: the login URL of the masterAPI Manager (for example,
  5. If you already have this servlet property, you can simply edit the value. If you list multiple URLs, separate them with a comma.
  6. Repeat the previous step on API Manager API v1.3.
  7. In the node tree, click Server Settings > General, and ensure that Server's SSL cert's name must match name of requested server is not selected.
  8. Click Server Settings > API Manager > Identity Provider, select Use external identity provider.
  9. Set Account authentication policy to the AuthenticateToMaster policy and Account information policy to Get Current Info, and click Save.
  10. Deploy the configuration to API Gateway.

Configure the connection to slave API Managers

  1. Log in to the Joomla! Admin Interface (JAI) (https://<API Portal host>/administrator).
  2. Connect to your master API Manager normally, see Connect API Portal to a single API Manager.
  3. Click Components > API Portal > Multiple API Managers.
  4. Enter the public label (for example, Environment) for the API Managers. An API consumer sees the available API Managers listed under this title.
  5. In Login Failure Policy, select how failed logins are handled.
  6. Click the + button to add a slave API Manager, and enter a public name for it. This name is shown in the list of API Managers available to an API consumer.
  7. Enter the host IP address and port of the slave API Manager.
  8. Configure the rest of the settings if required, then click Save.
  9. Repeat to add the rest of your slave API Managers.

After you have added the first slave API Manager, you can also add new API Manager instances by clicking the + icon in any of the slave API Managers. To remove a slave API Manager, you can click the X icon.

Related Links