product-apim: the WSO2 API Manager source, and what the four modules do

Four modules, and the module names describe the architecture

WSO2 API Manager is a complete platform for building, integrating and exposing digital services as managed APIs in the cloud, on-premise and hybrid architectures, and the repository layout is the clearest description of how that platform is put together.

There are four modules at the top level. `gateway/` is the data plane, the part that actually sits in the path of a request and applies the policies. `traffic-manager/` handles the load balancing and routing decisions across the gateway instances. `api-control-plane/` is the management side, where APIs, products, policies and users are defined. And `all-in-one-apim/` is the distribution that bundles all of it for a single-node evaluation or small deployment.

That split is a deliberate architectural choice and it is the one thing to understand before reading any of the code. A gateway that both routes traffic and holds the management configuration is simpler to install and much harder to scale or to run in multiple availability zones, because the control plane becomes a single point of failure for every request. Splitting them means the gateway can be scaled and replaced independently, at the cost of a distributed system to reason about. The all-in-one module exists precisely so that you can get the same code running as one process when you do not need the separation, and the two are the same code rather than a simplified edition.

Alongside them are `documentation/`, `release-notes.html`, `INSTALL.txt`, a `pom.xml` for the Maven reactor, and both `LICENSE` and `LICENSE.txt`. The root `README.txt` and `README.md` existing side by side is a small artefact of the project's long history.

It is Apache-2.0 licensed, the default branch is `master`, the last push was on 2026-10-15, and the release history is 4.7.0 on 2026-04-29 with two release candidates before it in April 2026. The copyright line runs from 2012 to 2026.

The runtime is the integration engine, not just a router

The interoperability section is where the platform's actual scope becomes clear, and it is broader than a gateway.

The first point is interoperability with open standards, achieving interoperability between diverse systems without vendor lock-in, using REST, GraphQL and AsyncAPIs.

The second is the one that catches people. The integration runtime supports creating composite microservices, message routing, transformation, message mediation, service orchestration, and consuming and processing streaming data. So the gateway is not a pass-through proxy with a policy engine bolted on. It is a mediation and orchestration runtime that sits in the request path and can reshape messages, route them, call other services and consume streams, and the gateway module is where that runtime lives.

That has consequences for evaluation. A team that wants a simple reverse proxy in front of its services will find an enormous amount of machinery here, and the configuration surface is correspondingly large. A team that wants to aggregate two backend services into one API, or transform a payload between systems, will find exactly the tool they need and will spend the first weeks learning the mediation sequences.

The extensibility section describes the third dimension, the ability to tailor authenticators, policies, mediations, API lifecycles, workflows, portals and login pages. The list of things you can replace is essentially the list of extension points, and it is a long one. The message to a technical team is that the platform is designed to be modified rather than configured, which is the difference between a product you can adapt and one you can only live with.

Running it means a JDK, a shell script and two web applications

The installation instructions are short, and they read like the installation instructions of a large server application, because that is what it is.

The product requires a JDK to run, and JDK v21 is supported, with a linked page listing the complete set of supported JDKs and tested operating systems. You set the `JAVA_HOME` environment variable to point at your JDK. Then you extract `wso2am-4.7.0-SNAPSHOT.zip`, go to the `bin` directory, and run `api-manager.sh` or `api-manager.bat` depending on your operating system.

After that you get two web applications on the same host, the API Publisher at `https://localhost:9443/publisher` and the Developer Portal at `https://localhost:9443/devportal`, both reachable with the default administrator credentials, username `admin` and password `admin`.

That last detail deserves a note rather than a repetition. The default credentials are documented, which is honest for an evaluation install, and they are also the reason a default install must never be exposed to a network. The port 9443 is HTTPS, and the whole thing starts with a single script that brings up a JVM with an embedded servlet container, which is the standard pattern for a Java web application that wants to avoid a separate application server.

The docs point out that if you run your workloads on Kubernetes, there is a specific solution for the Kubernetes platform, which is worth reading before you try to containerise the all-in-one distribution yourself, because the control plane and the gateway have different lifecycle requirements and a single all-in-one image is not the shape a Kubernetes deployment wants.

The master branch is unreleased code, and the issue trackers are split

Two details in the readme affect how you work with the project day to day.

The first is the branch model. If you are planning on contributing to the development efforts of WSO2 API Manager, you can do so by checking out the latest development version, and the master branch holds the latest unreleased source code. A clone of master is not a released product, and the version in the `pom.xml` and in the zip name is a `-SNAPSHOT`, so building from master gives you something between releases. For a team that wants to build and run the platform themselves, that means choosing deliberately between the released distribution and the development branch.

The second is where to file things, and there are three separate destinations. All known issues of WSO2 API Manager are filed at the `wso2/api-manager` issues repository, and the readme asks you to check that list before opening a new issue, and to submit bug reports and feature requests through GitHub at the same place. Security issues are explicitly excluded and have their own path, the WSO2 Security Vulnerability Reporting Guidelines, with a request not to report them via GitHub issues.

That split between a general issues repository and a separate one for this repository is a little confusing, and it is a consequence of the product's size and history: the code lives in `product-apim` while the tracker for known issues lives in `api-manager`. A contributor needs both.

The contribution guidelines are in `CONTRIBUTING.md` in this repository, and the `.github/` directory, `CODE_OF_CONDUCT.md` and `SECURITY.md` complete the standard set.

Where product-apim is the wrong tool

The first case is a team that wants a hosted API management service. This is a platform you install, operate, patch and back up, and the readme is explicit that it is a complete platform for the cloud, on-premise and hybrid architectures, which means a substantial deployment. A team that wanted a SaaS gateway is looking at a different product.

The second case is a team that wants something small. A JVM, an embedded servlet container, a gateway, a traffic manager and a control plane with two web interfaces is a lot of moving parts for an organisation that wants to put three services behind a proxy. If the requirement is authentication, rate limiting and a bit of routing, a lighter gateway or an API framework inside your own services is the better fit, and this platform will look like overhead.

The third case is a team that has standardised on a cloud provider's API management. The interoperability argument in the readme is about open standards and avoiding vendor lock-in, and it is a real argument, but a team that has already committed to a managed gateway is not evaluating alternatives for that reason.

The fourth is a team that expects the Apache licence to be the whole commercial picture. The readme is clear that WSO2 offers an on-prem product subscription for the full range of software product benefits an enterprise needs, expert support, continuous product updates, vulnerability monitoring, and access to the licensed distribution for commercial use. So there is a paid tier, and a team deploying this in production should read the subscription page before assuming the Apache-2.0 grant covers their use.

One last practical note. This is a large Java codebase with a long history, and the readme carries a survey about the open source community and communication preferences, which is a small sign of a project where the maintainers are actively trying to understand who uses it and how. That is a healthy sign for a platform that a lot of organisations depend on indirectly, and a reminder that the vendor relationship exists and matters.

Editorial conclusion

The repository fits an organisation that wants to run an API management platform it can read, extend and compile rather than a black box, and it fits a team building a custom authenticator, policy or mediation on top of the runtime. It does not fit a team that wants a hosted service, or one that needs the platform to be small, since the runtime is a substantial Java stack. Before you plan around it, read the installation prerequisites page for your target architecture, because the supported JDK is v21 and the operating system matrix is part of the product, and check the commercial support offering if you need vendor-backed deployment help.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wso2/product-apim on GitHub