API gateway pricing is the wrong conversation to be having in 2026

API gateway pricing looks like a straightforward procurement problem. Pick a vendor, model the request volume, negotiate the contract. But the exercise is quietly obsolete. The traffic profile that gateway pricing was designed around — human developers writing SDK calls into a documented public API — is not the traffic profile agent-era platforms are about to run. Teams comparing Kong, Apigee, and AWS API Gateway on price-per-million-requests are optimising the wrong line item.

We think the more useful conversation is what you're actually paying for, and whether the thing you're paying for solves the problem in front of you.

The four pricing models, briefly

API gateway pricing sorts into four shapes. It's worth naming them before arguing about them.
‍

At a glance, the comparison-shopping instinct is to model your traffic against each shape and pick the cheapest. That's how gateway procurement has worked for a decade. It's also why most enterprise teams are quietly overpaying — they modelled human traffic against pricing designed for human traffic, then discovered that neither the traffic nor the requirements match what their agent projects actually need.

The pricing comparison misses the real cost

An API gateway does three things: it fronts an API that already exists, it applies policy (auth, rate limits, quotas) to traffic hitting that API, and it gives you observability over the surface. The pricing conversation assumes all three of those are what you need.

For human developer traffic, that assumption holds. A developer reads the docs, gets an API key, writes some code, ships. The gateway sits in front, counts requests, enforces the plan they're on. Clean.

Agent traffic breaks two of the three assumptions.

First, agents don't call the API you documented — they call whatever tool surface you gave them. If your API exposes a small fraction of what your product can do (which, for most established SaaS platforms, it does — see your APIs expose 2% of what your product can do), the gateway is pricing traffic against a surface that doesn't include most of what the agent needs to reach. You're paying for governance of the wrong thing.

Second, per-request pricing assumes each request is doing roughly the same amount of work. Agents don't behave that way. A single agent turn might fan out into fifteen tool calls to complete one user intent. The gateway sees fifteen requests and prices accordingly. The user got one outcome. Your unit economics get worse every time an agent does its job well.

The pricing model is measuring the wrong unit.

What most teams are actually buying when they buy a gateway

When we talk to teams evaluating gateway spend, the honest answer for why they need one usually falls into one of three buckets. It's worth being clear about which one you're in, because the pricing conversation looks different in each.

Bucket one: fronting a public API for external developers. Rate limits, API keys, developer portal, docs. This is the classic use case, and the pricing models were built for it. If this is you, standard gateway comparison logic applies — model your traffic, pick a shape, negotiate.

Bucket two: internal service mesh and east-west traffic policy. This is a different product category entirely, even though the vendors overlap. Kong, Envoy-based options, and cloud-native ingress solve this. Pricing here is usually per-node or per-cluster, and the comparison is about performance and operational fit, not per-request cost.

Bucket three: giving AI agents access to your platform. This is where the pricing conversation goes off the rails. Teams buy a gateway, wire their agent into it, discover the API surface doesn't cover what the agent needs to do, and then spend more on custom integration work than they did on the gateway itself. The gateway wasn't wrong — it was just the wrong layer.

We wrote more about this split in AI gateway vs API gateway. The short version: an API gateway fronts APIs that exist. It doesn't generate the tool surface an agent actually needs. If you're in bucket three, the pricing conversation you should be having isn't about per-request cost — it's about whether a gateway is the right purchase at all.

The integration debt line item nobody puts on the RFP

MuleSoft's 2025 Connectivity Benchmark Report puts the cost of integration challenges — lost productivity and delayed projects — at around $6.8 million per organisation per year. Whatever the exact number is at your company, the shape is right: the cost of getting systems to talk to each other, and keeping them talking as they change, dwarfs the licence cost of the tools that sit between them.

API gateway pricing shows up as a line item on the finance spreadsheet. Integration debt shows up as engineering headcount, missed deadlines, and agent projects that stall between proof-of-concept and production. The second number is bigger, and the gateway pricing decision doesn't move it.

The reason it doesn't move is structural. A gateway prices the traffic flowing through a surface it didn't create. If that surface is missing the capabilities your agents need, cheaper gateway pricing just means you overpay less for the wrong thing. The real spend is what it costs to close the capability gap — usually through bespoke connectors, API rewrites, or ad-hoc scripts none of which compound across products (see the hidden cost of bespoke agent connectors).

If you're on an RFP for a gateway right now, the useful question isn't "how much will this cost per million requests?" It's "what does the surface I'm putting behind this gateway actually cover, and what am I going to spend closing the gap between that surface and what my agents need?"

A better set of questions than "whose pricing wins?"

So if per-request pricing comparisons aren't the right frame, what should teams actually evaluate?

We'd suggest four questions, in order:

1. What's the surface? Before you compare vendors, be honest about what your API actually exposes versus what your product can do. If the answer is "most of it," gateway pricing is a normal procurement decision. If the answer is "a fraction of it," the gateway is the wrong first purchase.
2. Who's the caller? Human developers using an SDK behave predictably. Agents fan out, retry aggressively, and hit endpoints in orders your docs didn't anticipate. Pricing that looked fine against human traffic can double or triple against agent traffic. Model both.
3. What's the maintenance cost? Every gateway configuration — routes, policies, transformations — is code you'll maintain forever. Pricing that looks cheap upfront gets expensive when your platform changes and the gateway config has to change with it. Ask vendors how their pricing behaves when your API surface evolves.
4. What does the runtime need to enforce? Agents raise the bar on auth (see agent identity vs user identity), rate limiting, and audit. Some of those requirements aren't well-served by traditional gateway pricing tiers — they need a runtime designed for tool execution, not HTTP proxying.

Answer those four, and the pricing comparison becomes narrower and more useful. You're not shopping for the cheapest per-request rate anymore. You're evaluating whether the layer you're buying actually holds up under the traffic you're about to send through it.

What follows from this

API gateway pricing isn't going away, and gateways aren't going away. For fronting a public API to human developers, they remain the right tool at roughly the right price. The market is mature and the vendors are competent.

But if the reason you're comparing gateway pricing is because you're trying to unblock an agent project, stop. The pricing conversation is a distraction from the harder decision underneath it — which is what your product's real surface looks like to an agent, and what layer of the stack should be responsible for making that surface reachable. A gateway can't answer that question, no matter how competitive its per-request rate. Get that decision right first, and the pricing question either becomes trivial or turns out not to matter.