The apiman project brings an open source development methodology to API Management, coupling a rich API design & configuration layer with a amazingly fast runtime. It is an open sources tool to design design,configure,manage and monitor rest API.

Installation Guide

1. Download
Tomcat 8.5.11 and apiman 1.2.9.Final overlay for Tomcat 8
2. Install
Unpack the Apache Tomcat 8 zip
Unpack the apiman 1.2.9.Final Tomcat 8 overlay zip inside the tomcat directory
3. Run Start Tomcat 8 using the default configuration Point your browser at the apiman UI and login with admin/admin123

4. Configure

The apiman distribution comes pre-configured with everything you should need to get started. Please see the User Guide for information about how to change apiman configuration options if you require more customization.
Or Linux User can just Follow these steps in terminal:

1. mkdir ~/apiman-1.2.9.Final and cd ~/apiman-1.2.9.Final
2. curl -o
3. curl -o
4. unzip
5. unzip -o -d apache-tomcat-8.5.11
6. cd apache-tomcat-8.5.11
7. chmod 755 bin/

To run this,use this command ./bin/ run

Logging In
1. Once apiman is running, you should be able to log in to the API Manager by pointing your browser at the following URL: http://localhost:xxxx/apimanui/ xxxx-port you defiend in server.xml in /conf folder in apache-tomcat-8.5.11 directory

2. You may log in with credentials admin/admin123!

3.Welcome Screen Dashboard.

4. Organizations.

The top level container concept within the API management project its called the organization. All other entities are managed within the scope of an organization. When users log into the API management system they must be affiliated with one or more organization. Users can have different roles within that organization allowing them to perform different actions and manage different entities.

4.1. To see your organization

4.2. To find your organization

5. Plans

A plan is a set of policies that define a level of service for an API. When an API is consumed it may be consumed through a plan. Please see the section on ‘API Contracts’ for more information. An organization can have multiple plans associated with it. Typically each plan within an organization consists of the same set of policies but with different configuration details.

For example, an organization might have a Gold plan with a rate limiting policy that restricts consumers to 1000 requests per day. The same organization may then have a Silver plan which is also configured with a rate limiting policy, but which restricts consumers to 500 requests per day.

Once a plan has been fully configured (all desired policies added and configured) it must be locked so that it can be used by APIs. This is done so that API providers can’t change the details of the plan out from underneath the client app developers who are using it.

5.1. Creating a Plan

Plans can be created easily from the ‘Plans’ tab of the organisation details page. Simply click the ‘New Plan’ button and then provide a plan name, version, and description. Once that information is provided, click the ‘Create Plan’ button. If successfully created, you’ll be taken to the plan details page.

6. Providing APIs

6.1. Creating an API

First the user must create an API within an organization. If an organization does not yet exist one can easily be created. See the ‘Managing Organizations’ section for details.

From the organization details page, navigate to the ‘APIs’ tab and click on the ‘New API’ button. You will be asked to provide an API name, version number, and description.

If successfully created, you will be taken to the API details page. From here you can configure the details of the API.

6.2. API Implementation

Every API must be configured with an API implementation. The implementation indicates the external API that the API Gateway will proxy to if all the policies are successfully applied. Click the ‘Implementation’ tab to configure the API endpoint and API type details on your API.

The ‘Implementation’ tab is primarily used to configure the details of the back-end API that apiman will proxy to at run time. You must configure the following:

Endpoint URL – The URL that apiman will use to proxy a request made for this API.
Endpoint Type – Currently either REST or SOAP (not presently used, future information)
Endpoint Content Type – Choose between JSON and XML, information primarily used to respond with a policy failure or error in the appropriate format.
Additionally, the ‘Implementation’ tab allows you to configure any security options that might be required when proxying requests to the back-end API. For example, if you are using two-way SSL to ensure full security between the API Gateway and your back-end API, you may configure that here. We also support simple BASIC authentication between the gateway and your back end API. Please note that BASIC authentication is not ideal, and especially insecure if not using SSL/HTTPS to connect to the back end API.

Do not forget to click the Save button when you are done making changes.

6.3. API Definition

As a provider of an API, it is best to include as much information about the API as possible, so that consumers can not only create contracts, but also learn how to make calls. For this purpose, you can optionally include an API Definition document by adding it to your API on the Definition tab. Currently the only supported type of definition file is Swagger. Include a swagger spec document here so that consumers of your API can browse information about your API directly in the API Manager UI.
6.4. Available Plans

Before an API can be consumed by a client app, it must make itself available through at least one of the organization’s plans (or it must be marked as “Public”). Marking an API as public or making an API available through one or more plan can be done by navigating to the ‘Plans’ tab on the API details page. The ‘Plans’ tab will list all of the available plans defined by the organization. Simply choose one or more plan from this list. If no plans are needed, you can instead mark the API as “Public”, making it available to be consumed anonymously by any client. Although an API can be both Public and available through one or more plan, it is unusual to do so. Tip

After you have either marked the API as “public” or selected at least one plan, make sure to click the Save button.

6.5. Managing Policies

API policies can be added and configured by navigating to the ‘Policies’ tab on the API details page. The ‘Policies’ tab presents a list of all the policies configured for this API. To add another policy to the API click the ‘Add Policy’ button. On the resulting page choose the type of policy you wish to create and then configure the details for that policy. Once you have configured the details click the ‘Add Policy’ button to add the policy to the API.

6.6. Publishing in the Gateway

After all of the configuration is complete for an API, it is time to publish the API to the runtime gateway. This can be done from any tab on the API details page by clicking the ‘Publish’ button in the top section of the UI. If successful, the status of the API will change to “Published” and the ‘Publish’ button will disappear. Tip

If the API cannot yet be published (the ‘Publish’ button is disabled) then a notification will appear near the button and will read “Why Can’t I publish?” Clicking this notification will provide details about what information is still required before the API can be published to the Gateway.

Once the API has been published, it may or may not be editable depending on whether it is a “Public” API or not. For “Public” APIs, you will be able to continue making changes. After at least one change is made, you will have the option to “Re-Publish” the API to the Gateway. Doing so will update all information about the API in the Gateway. However, if the API is not Public, then the API will be immutable – therefore in order to make any changes you will need to create a new version of the API.

6.7. API Metrics

Once an API is published and is being consumed at runtime, metrics information about that usage is recorded in a metrics storage system. See the Metrics section of the API Gateway documentation for more about how and when metrics data is recorded.

If an API has been used by at least once, then it will have metrics information available. This information can be viewed in the ‘Metrics’ tab on the API’s details page. On this page you can choose the type of metric you wish to see (e.g. Usage metrics and Response Type metrics) as well as a pre-defined time range (e.g. Last 30 Days, Last Week, etc…​).

The API Metrics page is a great way to figure out how often your API is used, and in what ways.

6.8. To View All API

6.9. Importing API(s)

As an alternative to manually creating and configuring an API, apiman also supports importing an API from a globally configured API Catalog.

7. Client Apps

A client app represents a consumer of an API. Typical API consumers are things like mobile applications and B2B applications. Regardless of the actual implementation, a client app must be added to the API management system so that Contracts can be created between it and the APIs it wishes to consume.

A client app consists of basic metadata such as name and description. Policies can also be configured on a client app, but are optional. Finally, API Contracts can be created between a client app and the API(s) it wishes to consume. Once the API Contracts are created, the client app can be registered with the runtime gateway. Policies and Contracts can be added/removed at any time. However, after any changes are made, you must re-register the client app.

7.1. API Contracts

An API contract is simply a link between a Client App and an API through a plan offered by that API. This is the only way that a client app can consume an API. If there are no client apps that have created API contracts with an API, that API cannot be accessed through the API management runtime gateway (unless of course the API is “Public”).

7.2 Policy Chain

A policy chain is an ordered sequence of policies that are applied when a request is made for an API through the API Gateway.

When a request for an API is received by the API Gateway the policy chain is applied to the request in the order listed above. If none of the policies fail, the API Gateway will proxy the request to the backend API implementation. Once a response is received from the back end API implementation, the policy chain is then applied in reverse order to that response. This allows each policy to be applied twice, once to the inbound request and then again to the outbound response.

8. System Administration

There are several “global” settings that must be configured/managed by an apiman administrator. These global settings are managed by navigating to the System Administration section of the API Manager UI.

8.1. Roles

Users must become a member of an organization before being allowed to manage any of the plans, APIs, or client apps contained within it. When a user is made a member of an organization, they are granted a specific role within that organization. Typical examples of roles are Organization Owner, API Provider, and Client App Developer. These roles each grant different specific privileges to the user. For example, a user with the Client App Developer role will be able to manage the organization’s client apps but not its APIs or plans.

The roles that are available when adding a member to an organization are managed in the Roles section of the System Administration UI. The apiman admin can create as many roles as she wishes, giving each one a name, description, and the set of permissions it grants. Additionally, certain roles may be automatically granted to users who create new organizations. At least one such role must be present, otherwise organizations cannot be created.

8.2. Policy Definitions

The policies available when configuring APIs, Plans, and Client Apps are controlled by the Policy Definitions known to apiman. These definitions are stored in the API Manager and are added by the apiman admin. Typically these are added once and rarely changed. But as new versions of apiman are released, additional policies will be made available. For each policy, a policy definition must be configured in the System Administration UI.

Additionally, it is possible for a plugin, when installed, to contribute one or more policy definitions to the list. This is a very common way for new policy definitions to be added to apiman.

8.3. Gateways

Apiman allows multiple logical Gateways to be configured. The Gateway is the server that actually applies the policies configured in the API Manager to live requests to managed APIs. When using apiman, at least one Gateway must be running and configured in the API Manager. However, there is no limit to the total number of Gateways that may be running. The typical reason to have multiple Gateways is when some APIs are very high volume and others are not. In this case, the high volume APIs could be published to a Gateway that can handle such load, while the low volume APIs could be published to another (perhaps cheaper) Gateway.

Another reason you may want multiple Gateways if if you need some of your APIs to be provided in a particular physical region and others in a different one. In this case, you may have a Gateway (perhaps clustered) running in a US data center, while another Gateway (different cluster) is running separately in a data center in Europe.

In all cases, the apiman admin must configure these Gateways in the System Administration UI. Each Gateway has a name, description, and configuration endpoint. The configuration endpoint is what the API Manager will use when publishing APIs and client apps into the Gateway.

When configuring an API Gateway you will need to include the authentication credentials required to invoke the API Gateway configuration REST API. Typically this user must have the ‘apipublisher’ role in order to successfully talk to the API Gateway. The Gateway UI includes a Test Gateway button which will attempt to contact the Gateway API with the credentials included. If successful, the test button will turn green. If unsuccessful, details about the failure will be displayed and the test button will turn red.

8.4. Plugins

Apiman supports contributing additional functionality via a powerful plugin mechanism. Plugins can be managed by an administrator within the API Manager UI. The plugin management administration page allows an admin to install and uninstall plugins.

8.4.1. Adding Plugins

The Plugin admin page has two tabs – one shows the list of plugins currently installed, and the other shows a list of “Available Plugins”. The list of available plugins comes from a plugin registry that is configured when apiman is installed (see the Installation Guide for details on how to configure a custom plugin registry). By default, the “official” apiman plugins will show up in the list.

A custom plugin is typically added by clicking on the ‘Add Custom Plugin’ button found on the “Available Plugins” tab. This allows you to install a plugin that is not found in the configured plugin registry. When installing a custom plugin, you must provide the “coordinates” of the plugin. All plugins are actually maven artifacts, and as such their coordinates consist of the following maven properties:

Group ID
Artifact ID
Classifier (optional)
Type (optional, defaults to ‘war’)
When installing a plugin from the plugin registry, simply locate it in the list shown on the “Available Plugins” tab and then click the “Install” action. This will again take you to the Add Plugin page, but with all of the appropriate information already filled in. At this point you should only need to click the “Add Plugin” button.

Plugins primarily are used to contribute custom policies to apiman. These policies are automatically discovered (if they exist in the plugin) when a plugin is added to the API Manager. Policies that have been contributed via a plugin will appear in the Policy Definitions admin page along with the built-in policies.

8.4.2 Uninstalling Plugins

At any time you may choose to uninstall a plugin. Note that if the plugin was contributing one or more policies to apiman, then the policy will no longer be available for use when configuring your Plans, APIs, and Client Apps. However, if the policy is already in use by one of these entities, it will continue to work. In other words, uninstalling a plugin only removes the policy for use by new entities, it does not break existing usages.

To uninstall a plugin, simply click the “Uninstall” action for the appropriate plugin on the “Installed Plugins” tab (it is likely represented as a button with a little X). After confirming the action, the plugin should disappear from the list.

8.4.3. Upgrading Plugins

If apiman determines that a plugin can be upgraded, then an “Upgrade Plugin” action button will show up for the plugin in the “Installed Plugins” tab. This action will be represented as an up arrow icon button. When clicked, you will be prompted for the version of the plugin you wish to upgrade to. The result will be that a new version of the plugin will be downloaded and installed, replacing the older version you had before. Note that any Plans, APIs, or Client Apps that were using the old version of the plugin’s policies will continue to use the older version. However, any new policies from the plugin added to entities will use the new version. In order to upgrade an existing entity to a newer policy, you will need to remove the old policy from that entity and re-add it. We recommend that you only do this if there is a compelling reason (e.g. a bug is fixed or a new feature added).

8.5. Export/Import Data

Apiman has a feature that allows an admin user to Export and/or Import data. You can access this feature by clicking the “Export/Import Data” link on the API Manager Dashboard page (admin only). This feature is useful for the following use-cases:

Backing up data
Migrating data between environments (e.g. Test→Production)
Upgrading between apiman versions
From the Export/Import UI page, simply click the “Export All” button if you wish to export all of the data in the API Manager. The result will be a downloaded JSON file containing all of your apiman data. This file can then be optionally post-processed (perhaps you want to migrate only a single Organization from your Test environment to your Prod environment). At some later time, you can import this file (typically into a different installation of apiman) by selecting it and choosing “Upload File”.

For more details,follow this link:

9. Calling of API in Postman with following params:

base-url= <https://localhost:8443/apiman-gateway/Tomcat_ttpl/>
appication-url= /geturl/1.0
parameters=input parameters required for calling API listed in Swagger Document