The three components
Gateway, control plane, portal: the role of each building block of an API platform, their operating regimes, and why they should be assessed separately.
Three technical building blocks carry the five pillars. They have different operating regimes, different availability requirements, and most vendors sell them under a single name. Separating them is the first step in a serious comparison.
| Component | Regime | Role |
|---|---|---|
| The gateway | Data path, synchronous | Applies the rules to every call |
| The control plane | Control path, asynchronous | Declares APIs, policies, contracts |
| The portal | Consumer side | Documentation, credentials, try it out |
Three different criticalities
The gateway sits on the path of every call: its failure stops traffic. The control plane can be down for several days with no consequence, provided the gateway keeps its last known configuration. The portal can be down with no effect on production.
A product that ties the three lifecycles together imposes the highest criticality on all three: a portal update becomes a risky operation on the production path. The question belongs in pre-sales. It is almost never asked.
What separation makes possible
Choose separately. Nothing forces all three to come from the same vendor. Keeping a gateway in place and changing the portal is a common and reasonable project. The portal is the most visible component, and the most often disappointing.
Deploy separately. Several gateways in several network zones, a single control plane: that is the hybrid topology described in internal and external.
Measure separately. A portal incident is not a platform incident. Conflating them skews the availability figures, and the decisions that rest on them.
Updated August 2026.