You are in a planning meeting, and someone says, "We need an API gateway." Three people nod. You suspect they are picturing three different things. One means a front door for partners to find and subscribe to your APIs. One means the controller deciding what traffic gets into a Kubernetes cluster. One means a layer that gathers many backend services into a single API for a particular kind of client. All three people used the same two words.
That is the confusion Christian Posta sorts out in an essay on the Solo.io blog, "API Gateways are going through an identity crisis." It is an older piece, but it still reads as current, because the muddle it untangles never went away. It separates the three meanings cleanly.
The first is the gateway behind API management. Its job is exposing, in the essay's words, "existing, curated, APIs that we want to share with others but share them on our terms." The second is the cluster ingress controller, which guards what traffic enters a Kubernetes cluster. The third is the API gateway pattern, a backend-for-frontends that curates many services into one API for a class of consumer.
You might wonder whether a service mesh makes all this moot. The essay says no. A mesh handles east-west traffic transparently at L7, while API gateways, it says, "live above the service mesh and with the applications (L8?)." It also offers a warning worth taping to a wall: keep business logic out of the management layer, because shared gateway infrastructure "has the tendency to re-create the 'all-knowing, all-being' (think Enterprise Service Bus) governance gate."
There are no numbers to audit in the essay, just a taxonomy and that warning. The product list has aged: Gloo is now Kgateway Enterprise, and Solo's newest work is agentgateway for LLM, MCP, and A2A traffic. But the three-way split holds up.
Now the catalog's turn, and it is about the company's own record. The APIs.io post uses the essay as a frame for reading what Solo.io itself exposes. On the Solo.io provider page, all 15 API pages belong to the first identity. They are the Gloo Portal Server, the self-service side of API management the essay describes: an API Products API for the curated catalog, a Subscriptions API for signing up to plans, an API Keys API and an OAUTH Credentials API for the security flows, and a Teams API for who is allowed to consume what.
You will not find the other two identities there. Ingress and the gateway pattern are configured declaratively through Kubernetes resources, which is why they do not appear as REST surfaces, and the catalog does not pretend otherwise. If you went looking for them in an API catalog, you would come away thinking they were missing, when they simply live somewhere else.
The scores for what is there are mixed. The Kin Score is 60.4, in the strong band. Developer ergonomics lead at 78.6, then discoverability at 76.7 and contract quality at 65.2. Access clarity sits at 50.0, and contract governance is lowest at 28.0. Agent Readiness is 34.8, labeled agent-ready, with the MCP server, agent skills, and error semantics lit, and the well-known catalog, delegated identity, protected resource metadata, and dynamic client registration dark.
Here is the turn. The essay asked readers to put each gateway at the level where it adds value. Measured from outside, Solo is legible at exactly one of the three levels it describes. And the weakest thing about the management API it does publish is governance, the very thing that layer exists to provide.
What you take away is practical. Before the next meeting where someone says "API gateway," ask which of the three they mean. When you evaluate a vendor, remember that an outside catalog sees only the surfaces that are published as APIs, so absence is not always a gap. And when you read a score, read the facets: a respectable composite can still hide a governance number that deserves a follow-up question.
Read the original: https://apis.io/2026/11/10/solo-io-names-three-kinds-of-api-gateway-and-the-catalog-measures-the-first/