Very few organisations run on a single API gateway. One team picks Kong for Kubernetes, another runs AWS API Gateway, and a legacy on premises gateway keeps serving traffic nobody wants to touch. Gartner expects that by 2028 more than 75% of organisations will use two or more API gateways. API gateway federation lets you govern all of them from one place, without moving a single API.
This guide shows how WSO2 API Manager 4.7 discovers APIs on Kong Gateway, keeps them in sync, and exposes them in one developer portal. No extra libraries or configuration files are needed: the Kong connector ships with the product.
Key Takeaways
- API gateway federation separates the control plane (WSO2 API Manager) from the runtime gateways, so APIs keep running where they already are.
- WSO2 API Manager 4.7 has a built in Kong connector. You need a Kong Konnect personal access token and three values from your Kong control plane.
- Discovery runs on a schedule. Changes in Kong create a new API revision in WSO2, not a duplicate.
- Kong and Envoy are discovery only. AWS API Gateway and Azure API Management also support deployment from WSO2.
- The catch: discovery does not rewrite Kong plugin policies into WSO2 policies. Plan that step separately.
The technical challenge: why do teams end up with multiple API gateways?
Teams end up with multiple API gateways because each platform decision made sense locally. Each gateway then becomes its own silo, with its own way to manage, secure, and expose APIs.
The problem is governance, not connectivity. Gartner warns that running gateways from different vendors without overarching API management “leads to API sprawl, shadow APIs and other governance challenges”. OWASP lists Improper Inventory Management as API9 in its 2023 API Security Top 10: APIs you do not know about are APIs you do not patch or retire.
Migrating everything onto one gateway is the obvious fix and usually the wrong one. It costs months, touches production routes, and throws away investments that work. Federation brings APIs under one governance model and leaves the runtime alone.
Architecture overview: how does API gateway federation work?
API gateway federation decouples the control plane from the runtime gateways. WSO2 defines a federated gateway as “an external API gateway that operates independently but is managed centrally through WSO2 API Manager”.
- Control plane: WSO2 API Manager, where you define, version, secure, and monitor APIs, and where the developer portal lives.
- Runtime gateways: wherever APIs are actually exposed. Kong, AWS, Azure, Envoy, or on premises, and often several at once.
You avoid a gateway migration, traffic stays close to consumers and backends, and consumers get one portal for every API. That pays off most in hybrid cloud, multi cloud, and geographically distributed setups.
For Kong, the connector runs in Read-Only mode. WSO2 polls the Kong Admin API, maps services and routes into WSO2 API definitions, and deploys a revision against the Kong gateway environment. Requests still hit Kong exactly as before.
Step by step: how to discover Kong APIs in WSO2 API Manager
You discover Kong APIs in WSO2 API Manager in eleven steps: connect both platforms (steps 1 to 4), let WSO2 discover and sync the API (steps 5 to 10), and call it from the Developer Portal (step 11).
Step 1: Generate a personal access token in Kong Konnect
WSO2 authenticates against the Kong Admin API with a personal access token (PAT). In Kong Konnect, go to Account > Personal access tokens and generate a token. Give it a clear name (here wso2) and an expiration date. You need it in step 3.
Step 2: Note your Kong control plane details
Open the Kong control plane you want to federate (here serverless-api-gateway-demo) and copy three values:
- The Proxy URL
- The Admin API URL
- The Control Plane ID
Step 3: Add Kong as a gateway environment in WSO2 API Manager
In the WSO2 Admin Portal, create a new gateway environment:
| Field | Value |
|---|---|
| Gateway Environment Type | Kong Gateway |
| Gateway Mode | Read-Only (WSO2 discovers APIs, it does not deploy them to Kong) |
| API Discovery Scheduling Interval | Polling interval in minutes, here 30 |
| Deployment Type | Standalone |
| Admin URL | Admin API URL host from step 2 |
| Control Plane ID | Control plane ID from step 2 |
| Access Token | PAT from step 1 |
| Vhosts | Proxy URL host from step 2 |
Save it. WSO2 now scans Kong for APIs on every cycle.
Step 4: Confirm the gateway environment is active
Check the server logs. The FederatedAPIDiscoveryRunner starts a discovery cycle for the new environment.
Step 5: Create an API in Kong Gateway
Create or reuse a normal Kong service. This example uses Test-Service with one route, posts, exposing GET /posts. Nothing about it is WSO2 specific.
Step 6: Watch WSO2 discover the API
On the next cycle, WSO2 picks up the service with no manual import, OpenAPI upload, or copied endpoints. It appears in the Publisher Portal as Discovered API: Kong, in CREATED state, with GET /posts mapped.
Step 7: Change the API in Kong
Add PUT, POST, and DELETE to the /posts route, plus a new todos route with GET /todos.
Step 8: See WSO2 pick up the change
On the next run, WSO2 recognises the existing federated API, updates it, and deploys a new revision. No duplicate is created, and the logs show each action.
Step 9: Check the updated API in the Publisher Portal
The API now shows GET, PUT, POST, and DELETE on /posts, plus GET on /todos. Nobody edited WSO2 by hand.
Step 10: Review the revision history
Every detected change creates a new API revision. The Deployments view lists them, with the latest deployed to the Kong environment. That gives you a versioned audit trail of every Kong side change.
Step 11: Call the Kong API from the WSO2 Developer Portal
Publish the API and open it in the Developer Portal. Call GET /posts from the Try Out console: the request goes to the Kong hosted backend and returns 200 OK. Discovery to invocation, end to end.
What does API gateway federation not solve?
Federation gives you one governed inventory. It does not make your gateways identical, so plan for three limits.
Discovery is scheduled. With a 30 minute interval, a new Kong route can take up to half an hour to show up in WSO2. Match the interval to how often your Kong teams ship.
Policies stay where they are. Discovery reads services and routes. Do not assume a Kong rate limiting or authentication plugin becomes a WSO2 policy. Align policies as a deliberate follow up.
The PAT is a run dependency. When the token expires, discovery stops and the portal drifts out of date. In our WSO2 operations work, this is the kind of issue that surfaces months after go live. Put token rotation in your runbook from day one.
Which other gateways can WSO2 API Manager federate?
WSO2 API Manager 4.7 federates four gateway platforms out of the box:
| Gateway | Discover | Deploy from WSO2 |
|---|---|---|
| Kong Gateway (standalone or Kubernetes) | Yes | No |
| Envoy Gateway (Kubernetes) | Yes | No |
| AWS API Gateway | Yes | Yes, OAuth 2.0 through a Lambda authorizer |
| Azure API Management | Yes | Yes, Microsoft Entra ID authentication |
Each API still lands in the same control plane, portal, and governance model. For a gateway not on the list, such as an in house one, you can build a custom gateway agent on the same federation framework.
Your next step
If you run Kong, AWS, Azure, Envoy, or a custom gateway and want WSO2 API Manager as the governance layer on top, discovery is the practical place to start. Your existing APIs show up in WSO2 within one discovery cycle.
Our enterprise integration practice helps architects map multi gateway estates, decide where federation beats a migration, and set up WSO2 API Manager as one governed control plane. Connext managed services then keep it patched, monitored, and in sync.
FAQ
What is API gateway federation?
API gateway federation manages multiple API gateways from one control plane. WSO2 API Manager governs and publishes the APIs, while traffic keeps running on gateways such as Kong, AWS, or Azure.
Do I need extra plugins or libraries to discover Kong APIs in WSO2 API Manager?
No. WSO2 API Manager 4.7 includes a built in Kong connector. You need a Kong Konnect personal access token plus the Admin API URL, proxy URL, and control plane ID.
Does discovering Kong APIs in WSO2 mean migrating off Kong?
No. In Read-Only mode WSO2 imports the API definition for governance and the developer portal. Requests still flow through Kong.
How often does WSO2 API Manager check Kong for changes?
You set the API Discovery Scheduling Interval in minutes. Each cycle adds new Kong APIs and updates changed ones as a new revision.
Also on LinkedIn: Saad Sahibjan wrote about this topic in API Sprawl and Shadow APIs: How to Govern Multiple API Gateways Without Migrating.
