WSO2 API Manager (APIM) is an open-source API management platform.
It helps organizations design, publish, secure, monitor, and manage APIs easily — whether for internal microservices or public developer portals.
When multiple services or systems expose data through APIs, we need to:
- Control who can access what
- Protect against unauthorized or heavy usage
- Track analytics and usage
- Support developer onboarding (documentation, keys, testing)
- Enable governance and versioning
That’s where WSO2 API Manager comes in.
Where API developers and architects create, design, and publish APIs.
Used for:
- Defining endpoints (REST/SOAP/GraphQL)
- Adding documentation, tags, and categories
- Versioning and promoting APIs to production
Where API consumers (developers, partners, teams) discover and subscribe to APIs.
They can:
- Explore API documentation
- Generate access tokens
- Test APIs directly from the portal
The runtime component that actually receives and routes API calls.
It enforces:
- Security policies (OAuth2, JWT, Mutual TLS, API Key)
- Rate limiting / throttling
- Logging, transformation, and mediation
Handles authentication and token issuance.
Integrated with WSO2 Identity Server, it manages:
- OAuth2 / OpenID Connect tokens
- API keys and JWT signing
- User/role-based access
Responsible for rate limiting and quotas.
Helps apply policies like:
- “Max 100 requests per minute per user”
- “Free vs. Premium subscription levels”
Collects logs and metrics:
- API usage per consumer
- Response time & error rates
- Dashboards for performance and adoption
flowchart LR
subgraph DevOps["Developer (Publisher)"]
PUBLISHER[Publisher Portal]
end
subgraph User["API Consumer (Developer)"]
DEVPORTAL[Developer Portal]
end
subgraph Runtime["Runtime Layer"]
GW[API Gateway]
KM[Key Manager]
TM[Traffic Manager]
end
subgraph Storage["Data Stores"]
REGISTRY[(API Metadata)]
ANALYTICS[(Logs & Metrics)]
end
PUBLISHER --> REGISTRY
REGISTRY --> GW
DEVPORTAL --> GW
GW --> KM
GW --> TM
GW --> ANALYTICS
🧩 Flow:
- API Developer designs API in Publisher
- Metadata is stored in Registry/Database
- Gateway serves requests
- Key Manager issues tokens & validates credentials
- Traffic Manager enforces rate limits
- Logs sent to Analytics
graph LR
A[Create] --> B[Publish]
B --> C[Deprecate]
C --> D[Retire]
B --> E[Re-Publish (New Version)]
- Create: API defined and documented
- Publish: API becomes visible in Dev Portal
- Deprecate: Old version still accessible but discouraged
- Retire: API removed from public access
graph TD
A[All-in-One] -->|"Single Node"| B[Development/Testing]
C[Distributed Deployment] -->|"Separate Gateway, KeyManager, Publisher, DevPortal"| D[Production Scale]
E[Hybrid Deployment] -->|"Control Plane + Data Plane"| F[Multi-Cloud / Regional]
- All-in-One: Easy for testing; everything runs on one server.
- Distributed: Each component runs separately for scalability.
- Hybrid (Control Plane & Data Plane): Central management with regional or cloud-specific gateways.
In large organizations or multi-cloud setups, WSO2 APIM supports hybrid deployment.
This separates management (control) from execution (data) for better scalability and security.
flowchart TB
subgraph CP["Control Plane (Management Layer)"]
PUB[Publisher Portal]
DEV[Developer Portal]
KM[Key Manager]
TM[Traffic Manager]
end
subgraph DP1["Data Plane - Region A"]
GW1[API Gateway A]
ANA1[Analytics Node A]
end
subgraph DP2["Data Plane - Region B"]
GW2[API Gateway B]
ANA2[Analytics Node B]
end
PUB --> KM
DEV --> KM
KM --> TM
CP -->|API Deployment| DP1
CP -->|API Deployment| DP2
GW1 --> KM
GW2 --> KM
GW1 --> ANA1
GW2 --> ANA2
- Control Plane manages:
- API design, publishing, key management, throttling, and analytics setup
- Central governance and configuration
- Data Plane(s) handle:
- Actual API traffic (runtime gateway)
- Regional or cloud-local deployments close to users
- Communication between planes is secured (token-based or mTLS)
- Control Plane in Head Office / Cloud HQ
- Multiple Data Planes in regional data centers (e.g., Singapore, Myanmar, EU)
- Each Data Plane processes API calls locally → low latency, high resilience
✅ Advantages
- Scalability — Add new regions easily
- Security — Keep customer data within region
- Reliability — Failures in one plane don’t affect others
- Governance — Central control, decentralized execution
WSO2 supports multiple authentication methods:
- OAuth2 / OpenID Connect
- API Keys
- Mutual TLS (mTLS)
- JWT validation
- External IDPs (Keycloak, Azure AD, etc.)
Policies and access control can be applied per API, per application, or per user role.
Scenario:
A bank wants to expose its internal payment APIs securely to partner fintechs.
- API team publishes
/v1/paymentsin Publisher - Partners register apps in Dev Portal and get tokens
- Partners call the API via Gateway
- Key Manager validates tokens
- Traffic Manager enforces rate limits
- Analytics shows API usage dashboard
| Component | Role | Typical User |
|---|---|---|
| Publisher | Create & manage APIs | API Developer / Architect |
| Dev Portal | Discover & subscribe | External/Internal Dev |
| Gateway | Secure & route traffic | System / Runtime |
| Key Manager | Issue tokens, auth | Security / IAM |
| Traffic Manager | Throttling, quotas | Ops / Infra |
| Analytics | Insights & reports | Product Owner / Ops |
- Developed by WSO2 (Open Source)
- Built on Java with Carbon framework
- Supports REST, SOAP, GraphQL, WebSocket APIs
- Integrates easily with Kubernetes, Docker, and CI/CD
- Latest stable version: WSO2 API Manager 4.x
- Use All-in-One for local testing (
docker-composeis available) - Always configure HTTPS and tokens before going public
- Use Publisher → Dev Portal → Gateway mental model
- Check logs under
/repository/logs/when debugging
🧠 In short:
WSO2 API Manager = “Control who, how, and how much can call your APIs — safely and visibly.”
References