Almost nobody arrives at this page greenfield. You already have APIs, already in production, already with consumers, already working well enough that nobody wants to touch them. What changed is that a second team now needs to call the first team’s service, or a customer asked for an API key, or somebody noticed authentication is implemented four slightly different ways across five services. Then a vendor call happens and the phrase “API management platform” appears.
The trouble is that the phrase covers three separate products. There is the gateway, which is a proxy sitting in the request path. There is the management platform, which is a control plane for policy, lifecycle and analytics. And there is the developer portal, which is a catalogue and self-service signup for the humans consuming your APIs. Vendors bundle all three and price them as one, so the evaluation turns into a feature grid where every row is checked and nothing is decided.
You usually need one of the three. Buying all three because they came together is how a two-person platform team ends up operating a distributed control plane for eleven internal services that never had an external consumer. So what follows is a map: what the three products actually are, what changes at each company size, and where to go for the specific decision you are trying to make.
Key takeaways
- A gateway is infrastructure in the request path. A management platform is a control plane around it. A developer portal is a product surface for external consumers. Different problems, different buying triggers, frequently sold as one SKU.
- If your APIs have no external consumers, you probably need a gateway and a spec, not a platform. The portal and the monetisation module solve a problem you do not have yet.
- The gateway is a new failure domain on the critical path of every request. That cost is real and is rarely discussed in a vendor evaluation.
- Pricing units differ structurally across the category: per request, per gateway node, per API product, per developer seat. The unit decides your bill far more than the feature list does.
Gateway, platform and portal are three products
The gateway is a reverse proxy that speaks your policy language. Every request goes through it. It terminates TLS, matches a route, runs a chain of plugins, and forwards upstream. Those plugins are the point: authentication, rate limiting, transformation, CORS, retries, circuit breaking. The value is that policy lives in one place instead of being reimplemented in every service by whoever was on call that sprint.
The cost is that you added a hop, and that hop can be misconfigured, overloaded or down. A gateway does not reduce your failure surface; it concentrates it. That is usually a good trade, because one well-operated component beats fifteen half-implemented middleware stacks, but it is a trade. The mechanism and its cost is the subject of the gateway comparison.
The management platform is the control plane. It is the thing that decides what configuration the gateway runs: which routes exist, which policies attach to them, who can change them, what happened when they changed, and what the traffic looked like afterwards. Concretely that means a configuration store, an admin API, RBAC, environment promotion, audit logging, and analytics over the gateway’s traffic.
This is where the enterprise money is, and where the genuine value sits once more than one team publishes APIs. A single team can keep gateway configuration in a Git repo and apply it in CI. Twelve teams sharing a gateway cannot, because the failure mode is one team’s route change breaking another team’s traffic, and that needs authorisation and an audit trail rather than a shared YAML file.
The developer portal is a product surface. Catalogue, reference documentation rendered from a spec, self-service key issuance, usage dashboards for the consumer, sometimes plans and billing. It exists to reduce the emails your team answers before a partner makes their first successful call.
If your consumers are three teams in the same Slack workspace, a portal is overhead. If they are hundreds of external developers you will never speak to, it is the product. That is the clearest dividing line in this category, and most of a portal’s value can be had from dedicated API documentation tooling without buying a platform underneath it.
What you actually need at each size
One team, a handful of services, no external consumers. You need consistent authentication and a place to put rate limits. A lightweight gateway configured declaratively from the repo covers it, and your control plane is the pull request. Write the OpenAPI spec first, because it makes every later decision cheaper, and put contract tests in CI so the spec stays true. The gateway to avoid here is the one that needs its own database and cluster to run at all. You are adding one hop, not a tier.
Twenty to eighty engineers, several teams publishing APIs, still mostly internal. Now the gateway config genuinely needs ownership boundaries, and someone has to answer “who called this endpoint and how often” when it breaks. This is the point where declarative config plus API monitoring and per-consumer analytics stops being optional.
It is usually still too early for a commercial management platform. What you need is an identity attached to each caller and a way to see traffic split by that identity, which a gateway with declarative config plus the metrics pipeline you already run covers. If you are on Kubernetes, the Kubernetes gateway options are a different shortlist, because config ergonomics and mesh overlap change the answer.
A platform team with internal customers, or any regulated environment. RBAC on gateway configuration, audit logs, environment promotion and change approval become the actual requirements, and they eliminate most of the market immediately. This is the first stage where a management platform earns its cost, because what you are buying is not features, it is letting teams self-serve without letting them break each other. Deprecation also becomes a scheduled process rather than an announcement, which is when versioning and sunset tooling starts mattering more than any gateway feature.
An API that is the product, with external paying consumers. Portal, plans, quotas, key lifecycle, usage metering and a support surface. This is the only stage where the full platform bundle is obviously worth it, and the evaluation should weight the consumer experience over the operator experience. A rate limiting design that is fair and explicable to customers matters more here than one that is theoretically precise. If you are also building the backend from scratch, the backend-as-a-service options collapse several of these decisions into one vendor, at the price of a deeper commitment.
Needs first-hand data: Put an identical service behind each of the major gateways with the same auth and rate limit policy, then measure added p50 and p99 latency, CPU per thousand requests, and memory at a fixed concurrency. This category has no honest published latency comparison, and the vendors have no incentive to produce one.
Kong Gateway
Kong is the most common answer in the self-hostable tier. The data plane is an Nginx and OpenResty derivative with a large plugin ecosystem, and it runs either fully declaratively from a config file or against a control plane with a database behind it. Konnect is the hosted control plane over the same data plane, which means the managed and self-hosted paths are the same proxy with different management.
Pros
- One data plane runs standalone, in Kubernetes, or under a hosted control plane, so the deployment decision is reversible
- Plugin ecosystem covers most policy needs without writing code, and custom plugins are genuinely writable
- Declarative config mode means the gateway can be owned by a Git repo rather than an admin UI
Cons
- The open source build and the commercial build diverge on exactly the features a platform team wants: RBAC, audit, multi-workspace
- Database-backed mode adds a stateful dependency to your request path that many teams underestimate
- Plugin ordering and interaction is its own operational skill, and misordered plugins fail in ways that are hard to read from logs
Best for: Teams that want a self-hostable data plane now, with the option to add a commercial control plane later without re-proxying.
Pricing: Open source build has no licence cost. The commercial offering meters on managed control plane usage and the number of data plane nodes or services under management, with enterprise plugins gated by tier.
Apigee
Apigee is an API program suite rather than a gateway, and that framing explains most of its behaviour. It assumes you have an API product with external consumers, a lifecycle with approvals, developers who need onboarding, and someone who reports on adoption. The proxy is real, but the proxy is not the thing you are buying.
Pros
- The most complete developer portal, API product and monetisation story in the category, by a wide margin
- Policy model and proxy revisions are built around versioned, promotable artefacts rather than live config edits
- Deep analytics on API consumption by developer and product, which is the reporting an API program actually needs
Cons
- Substantial conceptual overhead: proxies, products, developers, apps, environments and revisions are all distinct objects you must model correctly
- Heavily oriented toward Google Cloud, so running it as a neutral layer across clouds is possible but not the happy path
- Priced and sold as an enterprise program, which makes casual evaluation slow and makes it poor value for purely internal APIs
Best for: Organisations where the API is a commercial product with external developers, tiered access and someone accountable for adoption numbers.
Pricing: Subscription tiers gated by API call volume with separate entitlements for environments, monetisation and advanced security, sold on annual commitment.
AWS API Gateway
AWS API Gateway is the cloud-native managed option: no nodes, no capacity planning, and direct integration with Lambda, IAM, Cognito and CloudWatch. It comes in distinct flavours with materially different capabilities and prices, and picking the wrong one is the single most common mistake teams make with it.
Pros
- No infrastructure to operate at all, which for a small team is worth more than any feature on this page
- IAM and Cognito integration means authentication is configuration rather than a plugin you deploy
- Direct service integrations let you front Lambda, Step Functions or DynamoDB without writing a proxy service
Cons
- Per-request pricing makes high-volume, low-value traffic structurally expensive compared to running a node yourself
- Policy model is much thinner than a dedicated gateway; anything unusual becomes a Lambda authorizer or a custom integration
- Configuration is AWS-shaped and does not travel, so this is the deepest lock-in of the three by some distance
Best for: Teams already committed to AWS whose traffic is moderate and whose backends are mostly serverless.
Pricing: Per-request metering with separate rates by gateway type, plus data transfer and optional caching billed by cache size per hour.
How to choose
Answer these four questions in order and most of the market disappears before you book a demo.
Do your APIs have external consumers you will never meet? If no, you do not need a portal, plans or monetisation, and you should be evaluating gateways rather than platforms. If yes, the portal quality is the deciding factor, not the proxy.
Who is allowed to change gateway configuration? If the answer is “anyone with merge rights on the platform repo”, declarative config from Git is sufficient and a commercial control plane is premature. If the answer involves teams that cannot be allowed to break each other, you are buying RBAC and audit, and that is what to evaluate.
Where does the gateway run? In Kubernetes, the Gateway API and your mesh already do part of this job. On VMs, a single-binary gateway is hard to beat. On a cloud you are already deep into, the managed option removes work you would otherwise own.
What is the pricing unit, and what does your architecture produce a lot of? Per request punishes chatty internal traffic. Per node punishes running many small gateways for isolation. Per API product punishes fine-grained decomposition. Model twelve months forward, not today.
| Layer | What it actually is | Buy it when | Skip it when |
|---|---|---|---|
| Gateway | A proxy in the request path running policy plugins | You have more than one service and inconsistent auth | A single service can enforce its own policy |
| Management plane | Config store, RBAC, audit, promotion, analytics | Multiple teams share one gateway and can break each other | One team owns all config and reviews it in Git |
| Developer portal | Catalogue, docs, self-service keys, usage for consumers | Consumers are external and numerous | Consumers are three teams in your own Slack |
| Monetisation | Plans, quotas, metering, billing integration | The API is a revenue line with tiers | The API is internal infrastructure |
Needs first-hand data: Take one real API and time the full onboarding path in each candidate portal: signup, key issuance, first successful authenticated call, and first usage number visible to the consumer. Minutes to first successful call is the only portal metric that predicts support load, and nobody publishes it.
Frequently asked questions
Do I need an API gateway if I only have one service?
No. A single service can enforce its own authentication and rate limits with less latency and one fewer thing to operate. The gateway earns its place when the same policy must be identical across several services, or when policy has to change without redeploying application code.
Is a service mesh an API gateway?
They overlap and solve different problems. A mesh manages service-to-service traffic inside your cluster with identity between workloads. A gateway manages traffic entering from outside, where the caller is a customer rather than a workload you control. Running both is normal; running a mesh instead of a gateway leaves API keys and consumer quotas unaddressed.
Can I just use my cloud load balancer?
For routing and TLS, often yes. What a load balancer does not give you is a consumer identity model, per-consumer quotas, key lifecycle, or an analytics view of who called what. If you need those, you need a gateway.
How do I avoid lock-in in this category?
Migration cost is proportional to how much logic lives in vendor-specific plugins. Custom plugin code, vendor policy XML and cloud-specific authorizers are the parts that do not travel, so bound how much of any of them you write.
Should the gateway do authentication, or should the services?
The gateway should verify the token and reject anything invalid, so no unauthenticated request reaches a service. Services should still make authorisation decisions, because only they know what a caller may do with a given resource. Gateways that own fine-grained authorisation end up with business logic in proxy config, which is a bad place for it.
Related reading
- Best API gateways — what a gateway does in the request path, and the latency and failure domain it adds.
- Best API gateways for Kubernetes — Gateway API versus Ingress, mesh overlap, and operational complexity compared honestly.
- Kong vs Apigee vs AWS API Gateway — three different bets, compared on lock-in depth and what your team can operate.
- Best open source API gateways — which features sit behind the enterprise wall and what rebuilding them costs.
- Best rate limiting solutions — algorithms, distributed counter accuracy, and what happens to your limits during a partition.
- Best API monitoring tools — catching API failures your own gateway metrics will not show you.