The Developer Portal Awards highlight examples of excellence in developer portal experiences. Developer portals remain one of the primary ways organizations make APIs, data products, and other digital capabilities understandable, discoverable, and consumable.
The four lenses through which the awards observe excellence this year:
- A Unified or a Federated Enterprise Portal tells you how the organization governs a large API landscape.
- An API Product Microportal tells you how product teams communicate value and context.
- A Reimagined Onboarding Experience hints at how seriously the organization takes adoption.
- API Data Products reveal how it extends the same thinking beyond APIs.
Developer Portals in the Age of AI
It is difficult to have a conversation about APIs today without eventually arriving at AI. The vocabulary has shifted remarkably quickly. Agents, MCP servers, retrieval, orchestration: each offers a different perspective on how software may be consumed in the years ahead.
What has changed much less are the questions organizations continue to wrestle with.
- Can people find the capability they need?
- Can they understand whether it solves their problem before investing in integration?
- Can organizations continue to grow their API and data product portfolios without gradually losing coherence?
- Who owns the experience as more different teams contribute to it?
It is perhaps not surprising, then, that recent work on developer experience, API products, and AI continues to circle around the same concerns. Self-service, discoverability, onboarding, documentation, governance, and product context continue to reappear.
Developer portals rarely occupy the centre of these conversations. Yet, they are where those conversations become tangible. This is where an API portfolio begins to make sense beyond the boundaries of the teams that built it; where governance either supports or obstructs adoption; where product thinking becomes visible through the way capabilities are presented, explained, and connected.
Developer portals remain one of the few places where a broad set of architectural, product, and governance are encountered together rather than discussed separately. No portal tells the whole story of an organisation, nor should it. Yet it can reveal enough for experienced practitioners to recognise thoughtful work, appreciate difficult trade-offs, and learn from the experience that has been created.
If developer portals have become one of the places where these concerns come together, then there is no single way to evaluate them. A large enterprise platform solves different problems from an API product. A first-time onboarding journey deserves different attention from a mature data ecosystem.
Looking at them through a single lens would flatten those differences; the awards categories' different perspectives allow different forms of excellence to emerge.
The remainder of this article explains why the 2026 Developer Portal Awards focus on four perspectives that we believe reflect today’s most important developer portal challenges and best practices.
Enterprise Developer Portals and API Product Microportals
It is not uncommon to hear organisations ask whether they should build one developer portal or many. The question is understandable, but it also assumes that these are competing alternatives. In practice, they often answer different needs.
The challenge of helping people navigate an entire API portfolio and the digital capabilities it exposes is fundamentally different from helping them understand a single business capability. Both require thoughtful design, but helping people build a coherent mental model at a large portfolio scale is a hard-won part of a good experience.
On one hand, there is a need for a coherent entry point into an organization's digital capabilities. APIs, data products, event streams, MCP servers, and other interfaces need to be discoverable, consistently described, and connected in ways that make the portfolio understandable beyond the boundaries of the teams that created it. As portfolios grow and ownership becomes more distributed, the value of this shared experience becomes more apparent.
On the other hand, digital capabilities are rarely consumed as isolated technical assets. People are usually trying to accomplish something larger: integrate a business capability, work within a particular domain, or build on a specific product. That journey often spans multiple APIs, data products, and other interfaces, all of which benefit from being presented together within a coherent business context.
The exact scope of a microportal depends on the organisation and the problem it is trying to solve, not on a technical rule. A microportal may present a single API, a collection of related APIs, or a broader combination of interfaces and supporting resources that together enable a particular business capability.
A unified or federated developer portal helps people understand the landscape. A microportal helps them understand a business capability within that landscape. One provides the coherence that makes a growing portfolio navigable; the other provides the depth and context that allows individual business capabilities to be understood on their own terms.
Two awards categories reflect this complementary relationship, and together, they acknowledge that coherence and context are complementary qualities of mature developer portal programmes:
- Best Unified or Federated Enterprise Developer Portal recognises excellence in creating a coherent experience across a portfolio of digital capabilities.
- Best API Product Microportal in a Developer Portal recognises excellence in presenting a business capability with the clarity, context, and perspective it deserves.
Unified and Federated Developer Portals
People rarely wonder whether a portal is unified or federated. They notice when they cannot find their way.
The category recognises both unified and federated approaches because they represent different operating models rather than different aspirations. In both cases, the objective remains the same: helping people discover, understand, and navigate an organisation’s portfolio of APIs, data products, and other digital capabilities with confidence.
The distinction between unified and federated developer portals is less about what people experience than about how that experience is assembled and sustained.
A unified developer portal presents a single, coherent experience across a portfolio of digital capabilities. That coherence is often achieved through stronger central coordination of information architecture, governance, navigation, and publishing, even when many teams contribute to the portal.
A federated developer portal pursues the same objective through a different operating model. Responsibility for content and product experiences is distributed across business domains or product teams, while the overall experience is held together through shared principles, governance, and enough connective tissue for the portfolio to remain understandable as a whole.
From the perspective of someone using the portal, this distinction should matter very little. Whether capabilities are presented through a more unified or a more federated model, the expectation remains the same: a place where they can discover what is available, understand how different capabilities relate to one another, and move through the portfolio with confidence.
A unified portal typically achieves coherence through stronger central coordination, while a federated portal typically accomodates a broader range of technologies, products, publishing models, and organisational structures. Neither approach is inherently preferable.
The jury therefore does not evaluate how a portal is organised behind the scenes. It evaluates the experience those organisational choices create.
A federated portal is not expected to conceal the diversity of the domains it brings together. Different products or business areas may legitimately have different interaction patterns, structures, or visual identities. What matters is whether people can still understand where they are, how the pieces relate to one another, and navigate the portfolio with confidence.
Likewise, a unified experience is not inherently stronger simply because everything looks the same. Consistency is valuable when it creates clarity; uniformity without clarity is not a better experience.
Developer Portals for API Data Products
An operational API can often be understood by explaining its interface. A data product cannot. Understanding how to retrieve the data is only the beginning; people also need to understand what the data represents, where it comes from, how it should be interpreted, and whether it is appropriate for the decision they are about to make.
As data becomes more valuable, context becomes part of the product.
That context extends well beyond technical API documentation. Ownership, semantics, lineage, freshness, quality, licensing, compliance, intended use, and limitations are not supplementary information. Together, they allow people to develop confidence in the data they are about to consume and understand the responsibilities that come with using it.
This is what makes API data products distinct from operational APIs or microservices. An operational API primarily exposes behaviour. A data product exposes information assets whose value depends as much on their meaning as on the interface through which they are delivered. Developer portals therefore have a broader role to play: bringing together technical documentation, metadata, business meaning, and governance into a coherent experience.
The Best Developer Portal for API Data Products category recognises portals that meet this broader challenge. Whether presented as a dedicated portal or as part of a wider developer platform, the jury will be looking for experiences that help people understand not only how to access a data product, but also how to interpret it, use it responsibly, and develop confidence in the information it provides.
Reimagining Developer Portal Onboarding
Every now and then, someone questions an assumption we had quietly accepted.
Perhaps onboarding does not need to begin where we thought it should. Besides introducing people to an API, the portal has to help them understand how those capabilities are meant to be used. New interface styles, including AI-facing interfaces, create opportunities to rethink where onboarding begins and what confidence looks like during those first interactions.
The Best Reimagined Onboarding Experience in a Developer Portal category exists to recognise those moments. It does not favour a particular technology, protocol, methodology, or interaction model. Whether the onboarding experience introduces REST APIs, GraphQL, event APIs, MCP, or something else entirely is secondary to how effectively it helps people establish a first successful interaction.
Because this category is grounded in observable experience, nominations need to provide the jury with a way to experience that journey directly. The most compelling submissions will explain why their onboarding is different and allow the jury to discover it for themselves.
Every nomination adds another example to the body of work our community can learn from. We look forward to seeing what thoughtful teams have built. Nominations are open until 30 September, 2026.
