WSO2 Federates Kong APIs and Gateways
Kong
This pushes competition up a layer, because the buyer can keep Kong in the data path while moving governance, discovery, and developer onboarding into WSO2. WSO2 now documents built in support to discover APIs and gateway services running on Kong, sync them into its control plane, preserve definitions and security settings, and expose them through a unified developer portal. If that model sticks, Kong risks being judged more as interchangeable runtime infrastructure than as the system of record for API programs.
-
WSO2 describes federation as a way to avoid rip and replace. The pitch is aimed at large estates with multiple gateways after M&A, multi cloud rollout, or separate platform teams. In that setup, the economic value shifts to the tool that standardizes policy and catalog management across all of them.
-
On Kong specifically, WSO2 says it can discover APIs published in Kong Dev Portal and also detect gateway services that are not yet published as APIs. That means WSO2 is trying to sit above both Kong's public API catalog and its underlying service inventory, not just proxy traffic through Kong.
-
Kong still matters at runtime because it is where requests are actually routed, secured, and executed close to apps and users. But once another product owns the API inventory, lifecycle, and portal, day to day control moves toward the orchestration layer and away from the gateway vendor itself.
The next phase of API management looks more like multi gateway fleet management than single vendor standardization. If enterprises keep mixed estates and add AI and agent traffic on top, the winning products will be the ones that can impose one policy model across Kong, cloud gateways, and newer AI gateways without forcing a full migration.