How to choose an API management solution: a weighted framework

Choosing an API management solution is mostly a decision about where policy runs, who operates it and how hard it will be to leave. The leading products all list a gateway, a developer portal, analytics and rate limiting, so feature checklists rarely separate them. What separates them is the deployment model, the portability of their policies, the accuracy of their limits under load, the shape of the bill and, since 2024, whether they can meter traffic to language models in tokens rather than requests.

TL;DR

• An API management solution has six parts: gateway, policy engine, developer portal, analytics, lifecycle tooling and monetization. Judge each against the APIs you actually run.
• Deployment model (SaaS, self-hosted, hybrid, Kubernetes-native) decides latency, data residency and failure behaviour more than any single feature.
• Publish weights before vendor demos. Security and authentication standards, deployment fit and cost of ownership usually carry the most weight.
• Prove the shortlist with a proof of concept that runs production policies at production load, then compare three-year total cost of ownership.
• Model traffic is metered in tokens. Light usage can live in the API management layer; multi-provider, multi-team usage usually warrants a dedicated AI gateway alongside it.

This guide is a decision framework rather than a ranking. For a vendor-by-vendor comparison of the products named here, see the companion piece on API management platforms compared.

What API management covers

API management is the set of tools used to publish, secure, meter, document and retire APIs across their lifecycle. Microsoft’s documentation describes its own product as made of an API gateway, a management plane and a developer portal, and most vendors split the work the same way. Six capabilities sit inside that structure.

The gateway does the per-request work. Azure’s documentation lists the typical duties: it verifies API keys and other credentials such as JWTs and certificates, enforces quotas and rate limits, transforms requests and responses, caches responses and emits logs, metrics and traces. Policies are attached at several scopes; in Azure API Management a policy can apply globally, to a workspace, a product, an API or a single operation.

The developer portal and monetization features are what turn a gateway into a product. Kong’s Dev Portal, for instance, publishes APIs from OpenAPI or AsyncAPI specifications and supports internal, partner and public deployments. AWS API Gateway packages APIs into usage plans with API keys, quotas and throttling, and its documentation warns readers not to use API keys for authentication or authorization, and not to rely on usage plans to control costs.

API gateway or full API management

A standalone gateway handles traffic; API management adds the catalog, portal, subscription workflow and analytics around it. The Kubernetes project draws the line clearly: an API gateway aggregates unique application APIs and centralises functions such as authentication and request limits, while Gateway API is a set of Kubernetes resources that models service networking. Some API gateways can be programmed through Gateway API; neither is a full API management product. The difference between request-oriented API gateways and model-oriented gateways is covered in depth in the site’s piece on LLM gateways versus API gateways.

Deployment models for API management

API management products ship in four deployment models: fully managed SaaS, self-hosted, hybrid (vendor-run control plane, customer-run gateways) and Kubernetes-native (gateways configured through cluster resources). That choice sets where request data flows, what happens when the vendor’s cloud is unreachable and who carries the operational load, so settle it before comparing features.

Figure 1: Hybrid and Kubernetes-native models keep request traffic inside your network while configuration is managed elsewhere.

Hybrid deployments in practice

Hybrid is the model most enterprise buyers end up evaluating, and its failure behaviour differs by vendor. Kong’s hybrid mode splits nodes into a control plane and data planes, and if a Control Plane is offline, Data Planes will run using their last known configuration. Azure’s self-hosted gateway needs outbound connectivity on port 443, sends a heartbeat every minute and checks for configuration every 10 seconds, and is designed to “fail static” during an outage. That gateway is available only on the Developer and Premium tiers, which matters for pricing. Google describes Apigee hybrid as a management plane maintained by Google with a runtime plane the customer installs on a supported Kubernetes platform.

Self-hosted and Kubernetes-native options

Self-hosted gateways vary in how they store configuration. Kong documents three topologies; its traditional mode has every node connect to a database, while DB-less mode loads declarative configuration into memory and makes the Admin API read-only. Apache APISIX offers traditional, decoupled and standalone modes, with standalone loading routes from a local YAML or JSON file.

For clusters, the Kong Ingress Controller converts Ingress and HTTPRoute resources into gateway configuration, and MuleSoft documents its Envoy-based Omni Gateway (formerly Flex Gateway) as deployable as a Kubernetes ingress controller for high-availability cases.

Air-gapped and VPC-only requirements narrow the field further; the same constraints for model traffic are discussed in the site’s guide to on-premise LLM gateways.

Weighted criteria for API management

A weighted criteria table turns vendor demos into a comparable score. List each criterion, the evidence that proves it, and a weight that reflects your workload, then fix the weights before any vendor presents. The defaults below suit a mid-sized organization exposing partner and internal APIs; adjust them, but publish the adjusted version to stakeholders first.

Two adjustments are common. Organizations with heavy model traffic raise the AI weight to 15 or 20 and take the points from federation and the portal. Organizations selling API access raise monetization and portal weight, because plan management and billing hooks become revenue features rather than conveniences.

Security, standards and portability

Security criteria should map to published standards, not vendor adjectives. Check OAuth 2.0 and OpenID Connect support against RFC 6749 and its 2025 security best practice, check that the product imports and exports OpenAPI 3.x without loss, and test the gateway’s coverage of the OWASP API Security Top 10. Portability follows from the same standards: the more configuration lives in open formats, the cheaper an exit.

Authentication and the OWASP list

The OAuth 2.0 framework is the baseline for delegated access, and RFC 9700, published in 2025, updates its security advice: clients should not use the implicit grant unless token injection and leakage are prevented. A gateway that still pushes implicit-flow tutorials is behind the standard.

OWASP’s 2023 API Security Top 10 gives a checklist that maps cleanly to gateway features:

• API2:2023 Broken Authentication. OWASP notes that authentication mechanisms are often implemented incorrectly. Centralised token validation at the gateway addresses part of this.
• API4:2023 Unrestricted Resource Consumption. Attacks can lead to Denial of Service or an increase of operational costs, which is the case for rate limits and quotas, and for token limits on model APIs.
• API9:2023 Improper Inventory Management. OWASP stresses a proper inventory of hosts and deployed API versions, which is what a catalog and lifecycle tooling provide.

Object-level authorization (API1) and property-level authorization (API3) still have to be enforced in the backend; a gateway cannot know which customer owns which record. Treat any vendor claim of complete OWASP coverage with care. The model-specific counterpart, the OWASP list for LLM applications, is summarised in the site’s OWASP LLM Top 10 explainer.

OpenAPI as the portability layer

The OpenAPI Specification defines a language-agnostic interface description for HTTP APIs, and version 3.2.0 is current. Its Security Scheme Object covers API keys, HTTP authentication, mutual TLS, OAuth 2.0 flows including device authorization, and OpenID Connect. A management product that can import a 3.2 document, apply its security schemes and export it again keeps the API contract independent of the vendor.

Policies are the harder part to move. Azure API Management expresses policies as XML statements with policy expressions; Kong composes behaviour from plugins; APISIX configures plugins per route. None of these formats is portable between vendors, so estimate migration cost by counting custom policies and plugins, not APIs. Configuration as code (declarative files in Git, or Kubernetes resources) reduces that cost, because the intent is at least written down.

Traffic control, observability and overhead

Traffic control and observability are where proof-of-concept results diverge most from datasheets. Verify how rate-limit counters are shared across gateway nodes, how the gateway signals a limit, how telemetry reaches your existing backend, and how much latency the policies you will actually run add at your expected request rate.

Rate limits and quotas

RFC 6585 defines status 429 Too Many Requests and allows a Retry-After header; a gateway should return both so clients can back off. The harder question is accuracy across nodes. Kong’s Rate Limiting plugin documents three strategies, local, cluster and redis: local counters are fast but diverge as nodes scale, cluster counters are accurate but force a database read and write per request and are not supported in hybrid mode or Konnect, and Redis sits between the two. Every gateway makes some version of this trade-off, and the deployment model can remove options. The mechanics of limit algorithms are covered in the site’s rate limiting guide.

OpenTelemetry and analytics

The OpenTelemetry semantic conventions for HTTP spans are marked stable, so a gateway that emits them will line up with traces from the rest of the stack. Kong’s OpenTelemetry plugin provides metrics, traces, and logs in the OpenTelemetry format; Azure API Management integrates with Azure Monitor and Application Insights. Built-in dashboards are useful, but the criterion is whether a request can be followed from client to backend in the tool your operators already use.

Latency overhead

Vendors publish throughput figures under their own configurations, which rarely match yours. Measure added latency at p50 and p99 with the full policy chain on (token validation, rate limiting, logging, any transformation), at the request rate you expect plus headroom, and compare it with a direct call to the backend. A gateway that adds a millisecond with no policies can add far more once it calls an identity provider or a shared counter store on every request.

Pricing models and total cost of ownership

API management pricing follows four patterns: tiers with fixed capacity units, per-call or per-execution billing, per-node or per-gateway licences for self-managed software, and free open-source gateways with paid enterprise editions. The list price matters less than which features each tier unlocks and what the operating model costs over three years.

Tier gating is the first trap. Azure’s feature comparison notes that the Developer tier is for non-production use and has no SLA, multi-region deployment is a Premium feature, and the Consumption tier is a serverless gateway billed per execution. A hybrid design that depends on the self-hosted gateway therefore implies a Premium-tier budget. Kong’s AI rate limiting and MCP plugins are documented as part of its AI Gateway Enterprise offering, so model-traffic features may sit in a different commercial bundle from the core gateway.

Build the model per year for three years, include the staff time for upgrades and incident response, and price a step change in traffic (double the request rate) to see which model scales steeply.

Federation across several gateways

Large organizations rarely run one gateway. Acquisitions, cloud-native teams and platform migrations leave APIs spread across several products, so the question becomes whether the management layer can catalogue and govern APIs it does not proxy. Two patterns exist: workspaces inside one product, and federation that reaches into other vendors’ gateways.

Azure API Management supports a federated model with workspaces, where decentralised teams manage their own APIs while a central platform team keeps policy enforcement and a unified developer portal. Gravitee’s documentation describes a cross-vendor approach: its federation feature discovers APIs and event streams from AWS, Azure API Management, IBM API Connect, Apigee, Confluent and Solace, publishes them in one portal and manages subscriptions while consumers call the underlying platform directly. Federation is usually a catalog and subscription layer, not a policy layer; runtime enforcement stays with each gateway. Weight it highly only if you already have, or expect, several gateways.

Requirements for AI and LLM traffic

Model traffic differs from ordinary API traffic in three ways that affect selection: it is priced per token rather than per request, a single call can stream for minutes, and agents increasingly call tools over the Model Context Protocol. A management layer that meters requests can approve a call that spends thousands of dollars of tokens.

Token-based limits

Major API management products now ship token-aware policies. Azure’s llm-token-limit policy enforces tokens per minute or a token quota per key; exceeding the rate returns 429 and exceeding the quota returns 403 Forbidden, and it can precalculate prompt tokens to reject oversized requests before they reach the model.

Kong’s AI Rate Limiting Advanced plugin counts total, prompt or completion tokens, or cost, and Apache APISIX’s ai-rate-limiting plugin enforces token-based limits alongside its AI proxy plugins.

A worked comparison of token budgets attached to keys appears in this guide to LLM API rate limiting with virtual keys and budgets.

Model routing and failover

Routing for models means choosing a provider or deployment per request and falling back when one fails or is rate limited. Azure’s backend load balancer supports round-robin, weighted, priority-based and session-aware strategies, and its circuit breaker honours the backend’s Retry-After value.

APISIX’s ai-proxy-multi adds load balancing, retries, fallbacks and health checks across OpenAI, Anthropic, Gemini, Vertex AI, Amazon Bedrock and others, and can route by semantic similarity of the prompt.

MCP support

The MCP specification makes authorization optional for implementations, and when it is used, a protected MCP server acts as an OAuth 2.1 resource server. A gateway in front of MCP servers can supply the authentication, rate limiting and logging that many servers lack.

Azure API Management can expose REST APIs as MCP servers and front existing ones, and Kong’s AI MCP Proxy plugin applies OpenID Connect, rate limiting and logging plugins to MCP traffic.

Background on the protocol is in the site’s Model Context Protocol guide, and the identity questions are laid out in this explainer on MCP authentication with OAuth, API keys and token management.

When LLM traffic needs a dedicated AI gateway

A dedicated AI gateway is worth adding when model traffic involves several providers, several teams with separate budgets, or agents calling MCP tools. If model calls are few and go to one provider, token-limit and logging policies in the existing API management layer can be enough. The two layers are complementary: API management guards inbound consumer traffic, the AI gateway governs outbound model traffic.

Figure 2: The two layers meter different units: API management counts consumer requests, the AI gateway counts tokens and cost per model call.

The last row is often decisive. Model calls usually originate inside the network, from backend services, agents and developer tools, so they never pass the API management edge. The site’s comparison of LLM gateways and API gateways explains why the egress position matters, and this comparison of AI gateway and API gateway options for LLM traffic walks through the same split.

A survey of products for the egress layer is in the site’s ranking of AI gateways, and the cost side in its piece on LLM cost control with an AI gateway.

An AI gateway beside API management: Bifrost

A dedicated AI gateway adds token budgets per team, cross-provider routing, MCP governance and model-aware telemetry on the egress path. Bifrost, an open-source AI gateway from Maxim AI, serves as the worked example here because its source is public under Apache 2.0 and its documentation covers each AI criterion in the table above.

The project exposes 25+ providers and 10,000+ models through one OpenAI-compatible API. Bifrost’s published benchmark reports 11 µs of overhead at 5,000 RPS on an AWS t3.xlarge.

How it maps to the AI rows of the criteria table:

• Consumer identity. Virtual keys are the governance entity and are accepted in the OpenAI-style Authorization header, the Anthropic-style x-api-key header and others, so existing SDKs work by changing the base URL.
• Token-based limits and budgets. Request and token limits apply at provider-config, virtual-key, team and customer levels, and a request must pass every applicable level. Budgets follow a customer, team, virtual key hierarchy; this overview of hierarchical LLM budget management shows the pattern in more detail.
• Model routing. Routing rules use CEL expressions evaluated at runtime on headers, parameters, capacity metrics and organizational hierarchy.
• MCP. The gateway acts as an MCP client and can expose connected tools as an MCP server; tool calls are not executed automatically unless agent mode is configured, and tools are filtered per virtual key. Upstream servers can use OAuth 2.0, per-user OAuth, headers or token exchange.
• Observability. The OpenTelemetry plugin exports traces in the GenAI semantic conventions format to an existing collector.
• Deployment. The support matrix covers Helm on any Kubernetes cluster, EKS, GKE, AKS, ECS, Cloud Run and plain Docker, which fits the self-hosted and Kubernetes-native rows of the deployment table.

In this architecture the API management product keeps its edge role (partner keys, portal, request quotas) and the AI gateway receives model calls from inside the network. A fuller checklist for this layer is in the LLM gateway buyer’s guide and this buyer’s guide to AI gateways for LLM workloads. Teams comparing MCP-specific products can use the site’s MCP gateway survey.

Enterprise tier. Clustering for high availability, guardrails, SSO through OIDC and audit logs are part of Bifrost Enterprise.

A four-step selection process

A defensible selection runs in four steps: write requirements and weights, shortlist three or four products, prove them in a proof of concept with production policies, and compare three-year total cost of ownership. Each step produces an artifact the next one uses, which keeps vendor demos from setting the agenda.

Figure 3: Each step produces an artifact the next one depends on, so weights are fixed before any vendor demo.

1. Requirements

Start with an inventory, which is also OWASP’s API9 control: every API, its consumers, its protocol, its authentication method, its traffic and where its backend runs. Add non-negotiables (data residency, air-gap, identity provider, regulatory logging) and turn the rest into the weighted table. Record model traffic separately: providers, monthly tokens, teams and MCP servers.

2. Shortlist

Use the must-haves to cut the market to three or four products, mixing deployment models if the requirements allow it. The vendor-by-vendor detail lives in the platform comparison; the shortlist should be explainable in one sentence per product.

3. Proof of concept

Run each finalist against the same test plan, on infrastructure that resembles production.

4. Total cost of ownership

Price each finalist over three years with the cost table above, including staff time and the cost of leaving. Weighted scores and cost go to the decision-makers together, so a cheaper product that fails a must-have is visible as such.

Choosing with the weights in view

The right API management solution is the one whose deployment model, standards support and cost structure match the APIs an organization actually runs, proven under its own load. Publishing weights first, testing production policies in a proof of concept and comparing three-year costs makes the decision explainable after the fact, which is the real test of a selection process.

Model traffic adds one more decision. Token limits and MCP fronting now appear in mainstream API management products, and for a single provider they may be all that is needed. Once several teams call several providers, a separate AI gateway on the egress path, with API management kept at the edge, is the cleaner split. The criteria table works for both layers; only the weights change.