From APIs to value: The future of API Portals

APIs are the fundamental building blocks of Digital Transformation: They expose capabilities, and when used in the context of an API-First Strategy they also demand that everything that is getting built is conceived and designed as an API from the early stages of product inception and management. But APIs can only create value when they are being used, so it is critically important to think about API consumption as part of an API strategy.

Historically, API Gateways became the first API-oriented components that saw widespread use: It was clear that managing APIs with a gateway can help with issues such as security and access management. However, technically managing the APIs did not necessarily mean that they saw as much usage as was hoped for. API Portals were then conceived as a component on top of these gateways so that it would be easier for developers to find and use APIs. Developer Experience (DX) became the rallying cry that created a big push for API design and the use of API portals, leading us to today’s focus on APIs as products that should be easy to find and use.

However, most API portals are relatively tightly coupled to the gateway that they are using underneath, meaning that API management is constrained in some ways:

• It is only possible to expose the APIs managed in one gateway through the portal, meaning that it may be hard to expose sets of APIs that would make sense to be exposed in a single portal, but that happens to be managed in a multi-gateway environment.
• The focus of these portals is often rather technology-centric as they are driven by IT infrastructure (the underlying API gateway). With APIs becoming increasingly important at the business level, it does make sense to better decouple them from the technical details of IT infrastructure.

Allan Knabe of apiable.io presents the idea of Portal-as-a-Service (PaaS), which looks at portals from the consumption side, and allows to build an “API storefront” for those APIs that should become part of an API offering for a certain scenario.

This approach is a good fit for today’s move towards platforms, where the notion of the platform increasingly is driven by business considerations all the way to pursuing platform business models. In such a model, a platform very much is a business consideration, and building different portals for sets of consumers playing different roles on the platform should be easy, and should be driven by business considerations at least as much as by focusing on the needs of developers.

In this interview, we also talk about the concept of API catalogs as a component that can sit between gateways and portals. Using a catalog, API management can now be based on a unified view of the API landscape, and portals then can freely use all APIs in that landscape and are no longer restricted to be specific to a gateway.

The future of API portals is driven more by value considerations than by details of the IT infrastructure, and it makes a lot of sense to think of portals as components that can help with driving the value that APIs can generate. You can learn more about this different perspective on API gateways, portals, and catalogs in the following conversation with Allan Knabe.