What's New in the WSO2 Developer Portal: Self-Managed Deployment Option and Agent-Ready

Since they first hit the scene, developer portals have always done the same job: give developers a way to browse and consume the APIs they want to use. Now, with more agents consuming these APIs, compared to human users, things have had to change a bit to allow agents to also access and consume these same assets. The latest release of the WSO2 Developer Portal advances that job in three ways. It makes the portal run as a single, consistent experience across on-prem and SaaS, understands how to treat AI agents alongside with human developers, and it extends the catalog of available sources of APIs available through the developer portal to gateways beyond our own.

Why the portal needed to change

When we launched the API Platform to make enterprise APIs agent-ready, the Developer Portal was still catching up with the new architecture. We started by re-envisioning the Developer Portal experience and bringing those improvements to SaaS first and with this release, the same enhancements are now available for on-prem users too.

This flexibility carries through to how organizations adopt API Platform overall. Our API Platform provides all of the components that teams need, including the API Gateway and the Developer Portal, as individual components, so a team can start with exactly what it needs and add more as its requirements grow. Each of the components offers full deployment flexibility whether teams want to use SaaS, self-managed (for on-prem and air-gapped deployments), or a hybrid approach.

This release addresses the portal side of that shift directly with three main changes. Rather than walk through everything in the release notes, here are the three changes that matter most and why we made them.

1. Unification of on-prem and SaaS developer portals

The on-prem and SaaS Developer Portals now share the same codebase, UI, and configuration model. Theming, API documentation, application and subscription management, and SDK generation work the same way regardless of where the portal is deployed.

That matters for two groups in particular. Platform teams evaluating WSO2 API Platform in the cloud before committing to an on-prem rollout can now trust that what they configure and test in SaaS carries forward, instead of re-learning a second UI once they move on-prem. Organizations already running both, say a SaaS pilot for one business unit alongside an on-prem deployment for another, get one set of docs, one theming workflow and one support model to maintain instead of two. If you're in that position today, nothing about this release forces a migration. The unification shows up the next time you upgrade either deployment.

Portal theming is part of that shared foundation. Organizations can generate a Developer Portal theme automatically from their existing website using AI-assisted theming, rather than hand-building CSS to match brand guidelines. That capability now works the same way in both deployment modes. Organizations that want more control can still theme manually instead, setting colors, typography, HTML and CSS at the organization level.

The portal is also configurable to match what an organization actually publishes. Admins can set it to show API proxies only, MCP servers only or both. So the same portal fits an API-only team, an MCP-only team or an organization running both side by side.

2. Agentic readiness of APIs

The second change is less about where the portal runs. It’s about who or what is doing the browsing. Increasingly, that's an AI agent rather than a developer clicking through a UI. The AI agent querying your API catalog is no longer an edge case the portal happens to tolerate. It's a consumer that the portal is built for.

The Developer Portal exposes an llms.txt entry point alongside machine-readable Markdown for the API catalog, individual API documentation and API specifications. So an agent can enumerate what's available and pull the details it needs without scraping rendered HTML built for humans. That same discovery path extends to MCP servers published through the portal's MCP catalog and to API workflows described using the Arazzo specification, so an agent can follow a multi-step API sequence.

A developer browsing the portal and an agent querying it through llms.txt are reading from the same underlying catalog, with visibility controls determining what either one can see. For teams building internal agents or exposing APIs to customers' agents, this means the Developer Portal now doubles as the discovery layer those agents rely on.

3. Third-party federated gateways

The third change addresses something that comes up constantly in larger organizations. Many large organizations end up using different API gateways from different vendors. That results in a situation where there is no single point of discovery and consumption in the organization. This makes developers navigate to different portals to get access to different APIs.

This release adds discovery support for third-party gateways, beginning with AWS API Gateway, so the Developer Portal can become a developer portal for any API. It does not limit to APIs that are already running through a WSO2 gateway. APIs that already live on a supported third-party gateway can be pulled into the same catalog developers and agents search through the Developer Portal, under the same governance and visibility rules as everything else. The portal becomes a single front door for API discovery even when the backing gateways are not.

What this means for teams evaluating WSO2 API Platform

These three changes point in the same direction, leading teams to a clearer path for how the Developer Portal behaves, whether that's deployment mode, what it shows, who's consuming it, or which gateway sits behind it. A platform team no longer needs to choose between piloting in SaaS or committing to on-prem before they understand the product. A team exposing APIs to agents doesn't need a separate discovery mechanism outside the portal and a team with APIs scattered across multiple gateways gets one catalog instead of several.

If agent-facing API discovery or gateway consolidation is already on your roadmap, this release is a good moment to revisit your Developer Portal deployment plan. Start with the documentation for AI agent discovery and API workflows with Arazzo, or see how theming the portal with AI works today.