Apiman Features

A non-exhaustive list of Apiman's API Management features. Most of Apiman's functionality is customisable, and you can write your own plugins to provide capabilities that are not available out of the box. The Apiman team and community have also created a wide range of plugins that you can use.

Apiman should work on all operating systems that Java runs on.

  • Full Support
  • Partial Support
  • On Roadmap
  • Unsupported

API Manager

Standalone API Manager
Apiman has a fully-featured API Manager that is decoupled from Apiman's API Gateways. If the Apiman Manager goes down, your gateways can continue running as usual (you can configure your gateways to use a separate data store, too).

Apiman has a rich set of default policies, allowing you to govern and alter traffic transiting the Apiman Gateways in myriad ways. You can also create your own Apiman policy plugins, allowing you to create your own functionality.

See the policies and extensibility sections.

Policy Chain
Multiple policies are applied in an ordered chain defined by the user. This means you can combine functionality in the way that makes sense for you. It is also possible for policies to collaborate by passing messages to each other.
Apiman supports multiple versioned plans, allowing you to offer the same APIs with multiple different levels of service. For example, different rate limits for gold vs silver plan.
API consumers (Clients) can subscribe to multiple APIs and get their API keys, plus managing their client's lifecycle (e.g. breaking contracts).
API Documentation
You can attach OpenAPI v2 or v3 schemas (or Swagger), amongst others. Rendered into HTML for API consumers in both the main Apiman Manager UI and the Developer Portal.
Apiman is based around 'organizations', which are similar conceptually to a GitHub org. Users can create and join organizations, and be assigned fine-grained permissions within that org.
Roles & Permissions

Apiman has a hybrid RBAC-ABAC system.

Roles are globally defined personas that are assigned permissions (e.g. 'API Plan Administrator' has a range of plan-related permissions such as planAdmin).

Within an organization, Apiman users are assigned roles that grant them the permissions from that role.

Exposing APIs Publicly
APIs and plans can be exposed read-only to consumers who are not members of an organization. Conceptually, this is similar to a GitHub public repo; people can read and clone, but not modify.
Public APIs (Keyless APIs)
Publish an API without an API key and plan. You can still apply policies directly to the API itself. This feature name is confusingly similar to the previous entry, but is functionally completely different.

Apiman only supports post-hoc billing/monetization via metrics (e.g. Elasticsearch), but has no explicit support currently for up-front billing or payment capture.

Please provide your ideas and feedback in this feature request.


In-browser/API notifications for a range of Apiman events, such as when an API signup needs approval, when someone signs up to an API, etc. Many are interactive, allowing the user to click through into the relevant resource.

We're continuing to add more as we identify useful events to notify users about. Can be disabled.

Email Notifications
A fully templated and i18n-compatible email notification system to send a range of important Apiman notifications (subset of those that appear in-browser). Apiman selects the language to use based on the user's locale. Can be disabled.
Apiman Events

A new feature in 3.x, Apiman now publishes a range of events into an outbox table. By using CDC software such as Debezium, you can publish these events into event distribution platforms such as Kafka.

These events cover a range of topics, such as important entity state changes (e.g. API publication), and when actionable events occur (e.g. approval required).

You can use Apiman events integrate with external systems, such as business rules engines.

API Search/Discovery
List and search for APIs published in Apiman, including by wildcard patterns (globally and per-organization).
API Registry

Apiman has a simple JSON-based API Registry capability out of the box to list external APIs that users can import.

By implementing a simple interface, you can interrogate your own registry instead.

Please provide your ideas and feedback in this feature request.

The Apiman Manager's entire configuration can be exported as a JSON file and imported into a fresh Apiman installation. This is useful for backup, upgrades, and migration.

API Lifecycle

Draft your APIs without publishing them until you are ready.
Create multiple versions of APIs, Plan, and Clients. By default, versions are immutable (i.e. can't change policy configuration).
Multiple Envs
Create and publish APIs to multiple environments, for example testing vs production.
APIs can be published to one or more gateways/envs. This allows API consumers to find and subscribe to your API via a plan, receiving their API key.
APIs can be retired by the API provider. Retirement revokes access for existing users, and no new subscriptions can be made.
Apiman has simple in-built metrics and visualisations. There are also a range of metrics emitters for the Apiman Gateway, including Elasticsearch, Prometheus, InfluxDB, JDBC, etc. These are commonly combined with visualisation tools such as Kibana and Grafana to provide rich data insights.
Force Update Published Entities

Apiman imposes immutability on configurations of published APIs and Plans. This is to ensure that API publishers cannot silently alter the contract established between the API publisher and API consumer (e.g. change rate limits without telling consumer). A new version is usually required.

However, there are some situations where forcing a configuration update may be more appropriate, such as updating endpoints or fixing config mistakes.

Please provide your ideas and feedback in this feature request.

API Signup Approval

You can set APIs to require manual approval before a subscriber is allowed to use it. This is typically used for APIs that require a due diligence process.

Apiman sends notifications to approvers, and the subscriber receives notifications on acceptance or rejection.

Events are also emitted, if you want to handle this automatically.

API Mocking
Apiman does not have any direct support for mocking at present. However, we are considering integration with Microcks, a comprehensive REST mocking platform.

Please provide your ideas and feedback in this feature request.

API Gateway

Apiman gateways scale independently of the Apiman manager. You can have as many gateways as you need in a group to handle your load.
Gateway Independence
Apiman's gateways will continue functioning even if the Apiman Manager goes down. They can be configured to have different backing datastores, as well.
Multiple Gateway Clusters/Envs
You can set up multiple logical groupings of gateways, which you can publish your APIs to independently. This is commonly used to provide development vs production environments or regional segregation.
The Apiman Gateway uses asynchronous patterns throughout its codebase, including policy and component implementations. When you use the Vert.x gateway, then you will get a fully asynchronous experience.
Multiple Platforms
Apiman currently supports Vert.x, WildFly, and Tomcat. Best performance is achieved using Vert.x.
Apiman Gateway can be directly embedded into a Java application by implementing a series of interfaces and components. This requires considerable effort and understanding of the platform, but has been done a number of times.

Developer Portal

Standalone Devportal
Standalone Angular application that can be deployed separately from the rest of Apiman. It just needs to be able to speak to the Apiman Manager API.
A range of easy CSS customisations are available to make the devportal match your organisation's look and feel, including colour palate and images.
Simple Content Customisation
Simple JSON file-based customisations to change company names, custom links, custom footer, various standard text blocks such as legal prose, etc.
Explicit Publication
API providers can explicitly choose which APIs and plans to publish to the devportal, and hence can be seen by anonymous users. When a developer is logged in they can see everything their account is entitled to.
User Segregation
Devportal users can be segregated from other Apiman users to limit what they are allowed to do in Apiman. Simply assign the user the devportal role in Keycloak.
API Marketplace
APIs can be discovered via searching and lists. You can 'feature' an API to display it more prominently on the front page.
Markdown API Docs
API publishers can provide markdown documentation, which will be rendered in the developer portal alongside rendered any API schema. This commonly used for code samples, example payloads, etc.

You can set a global legal prose that all devportal users have to accept before signing up to an API.

If there is interest, we are considering adding a more fine-grained approach for managing legal prose that is attached to plans or APIs.

Please provide your ideas and feedback in this feature request.


Custom Policy Plugins

Policies govern traffic transiting the Apiman gateway. For example, rate limiting, security, or header and payload manipulation.

Using simple Java plugins, you can develop your own Apiman policies, enabling almost any kind functionality you can dream of, including schema-based UIs.

Schema-based Policy UI
Developers can provide a JSON schema with their custom Apiman policies. This allows users to configure your policy in the Apiman Manager UI. Apiman will render the schema into a form, and validate the policy inputs as per your rules.
Policy Plugin Testing
Apiman has a JUnit-based testing framework to allow robust testing of your custom logic.
Override Default Components
All Apiman's components can be replaced dynamically by user-provided plugin implementations simply by referencing your implementation in apiman.properties/conf.json. For example, you could provide a custom rate-limiting component implementation.
Custom Components
Using Apiman's standard plugin format, you can create new components and use them from your Apiman policies.
Dynamic Plugin Loading
All Apiman Plugins can be loaded dynamically at runtime, no restart is required. Policy plugins can be managed via the plugins administration page in the Apiman Manager. Component plugins are simply referenced directly in config by their URN.
Plugin Upgrades
Apiman plugin policy versions can be upgraded via the API or Apiman Manager administration console.
Plugin Repository
Apiman plugins can be loaded from (either automatically or via configuration):
  • Maven Central
  • Any Maven-compatible remote repository, such as Sonatype, JFrog, or Archiva.
  • Local ~/.m2.
  • User-defined alternative directory.
Local resolution can be useful for 'baking' plugins into containers in immutable architectures.
Custom API Registry Plugin

By implementing a simple interface, you can allow Apiman to search for and import APIs from external API registries.

For example, if you have an API registry inside your organization, your custom Apiman registry could interrogate it, allowing users to quickly import those APIs into Apiman with its implementation details pre-filled.

Custom Metrics Plugin
Apiman captures a rich set of metrics on traffic transiting the Apiman Gateways. A range of metrics implementations are provided out of the box, but you can also implement your own via a plugin.



Apiman is currently primarily an HTTP API gateway. For example, your RESTful Web API will work just fine.

Various protocols can run on top of HTTP, these should also work. Please let us know your results.

Set SOAP type in the implementation tab when defining your API in Apiman.
Apiman does not currently have explicit testing or support for Websockets, but we have been informed that certain setups will work (initial negotiation and handoff by HTTP, rest of connection out-of-band).

If you would like this feature adding, please open a feature request ticket.


If you would like this feature adding, please open a feature request ticket.

Messaging protocols

If you would like this feature adding, please open a feature request ticket.

Standard Policies

Policies are the bread and butter of Apiman, governing traffic passing through the Apiman gateway at runtime. They perform a wide variety of actions, including permitting or denying requests, modifying metadata (e.g. headers), and mutating the payload.

In this section, we briefly list the standard policies and plugins that ship with Apiman. Refer to the Apiman documentation for full information on functionality and configuration.

A key feature of Apiman is that you can create your own Apiman policies, and we welcome contributions. Refer to our developer's guide for more.

This policy enables fine grained authorization to API resources based on authenticated user roles. This policy can be used to control precisely who (authenticated users) are allowed to access the API, at an arbitrarily fine-grained level.
This policy enables HTTP BASIC Authentication on an API. In other words, you can use this policy to require clients to provide HTTP BASIC authentication credentials when making requests to the managed API.
Caching Resources
Allows caching of API responses in the Gateway to reduce overall traffic to the back-end API. The Resource Caching Policy can cache requests based on their URL path, http method and specific status code.
Ignored Resources
The ignored resources policy type enables you to shield some of an API’s resources from being accessed, without blocking access to all the API’s resources.
IP Allowlist
Allows access to an API’s resources based on the IP address of the client application.
IP Blocklist
Blocks access to an API’s resources based on the IP address of the client application.
The Quota Policy type performs the same basic functionality as the Rate Limiting policy type, however, the intended use of this policy type is for less fine grained processing (e.g., 10,000 requests per month).
Transfer Quota
Transfer Quota tracks the number of bytes transferred (either uploaded or downloaded) rather than the total number of requests made.
Rate Limiting
The Rate Limiting Policy type governs the number of times requests are made to an API within a specified time period.
Time Restricted Access
This policy is used to only allow access to an API during certain times.
URL Rewriting
Re-write URLs in responses from the back-end API according to patterns provided.
API Key Plugin
This plugin provides a policy that can help pass the API Key through to the back-end service.
Circuit Breaker Plugin
This plugin has policies for performing circuit breaker functionality.
CORS Policy Plugin
This plugin implements CORS (Cross-origin resource sharing): A method of controlling access to resources outside of an originating domain.
Header Allow/Deny Policy Plugin
Provides a policy that permits or denies requests matching certain HTTP headers.
HTTP Security Policy Plugin
Provides a policy which allows security-related HTTP headers to be set, which can help mitigate a range of common security vulnerabilities.
JSONP Policy Plugin
A plugin that contributes a policy that turns a standard RESTful endpoint into a JSONP compatible endpoint.
Keycloak OAuth Policy Plugin

This plugin offers an OAuth2/JWT authentication policy that leverages the Keycloak SSO platform as the identity and access provider.

Much of its functionality can actually be used by a wider range of SSO providers than just Keycloak.

Roles can be extracted and used with authorization policies, or injected into headers to pass to backend services

JWT Policy Plugin
A simple generic JWT auth policy (try this is the full-fat Keycloak plugin does not work for you).
Log Headers Policy Plugin
A policy that logs the headers to std out. Useful to analyse inbound HTTP traffic to the gateway when added as the first policy in the chain or to analyse outbound HTTP traffic from the gateway when added as the last policy in the chain.
Simple Header Policy Plugin
Offers a simple policy that allows request headers to be added or stripped from the HTTP request (outgoing) or HTTP response (incoming).
XML<->JSON Transformation Policy Plugin
This plugin provides a very simple policy which can transform the request and/or response payload between XML and JSON.
Your Custom Policy Plugin

You can implement your own custom policy plugin using Java.

You can make Apiman do almost anything!

See the extensibility section.

Identity & Access Management

For logging into Apiman Manager, Apiman Devportal, and managing access to the Apiman platform. You can also use your IDM/IAM solution with some Apiman policies (e.g. OAuth2 policy), but this is not mandatory.

Apiman is supports Keycloak IDM out of the box. This allows a multitude of security, federation, SSO, and user management duties to be delegated to a specialist platform.
Tomcat's simple auth mechanism is supported, but likely quite basic for real deployments. You can substitute it with Keycloak.

Feature supportedThe feature is fully supported by Apiman.Feature partially supportedThere is partial support for this feature in Apiman.Feature unsupportedThere is currently no support for this feature in Apiman.Feature unsupportedThere is currently no support for this feature in Apiman.