API gateway vs iPaaS: which one fits the problem you actually have

API gateways and integration platforms get confused constantly. Both sit between systems. Both handle authentication. Both show up in the same architecture diagrams. But they solve different problems, and picking the wrong one turns a six-week project into a six-month rebuild.

This comparison is for platform engineers, integration leads, and CTOs choosing between an API gateway and an iPaaS — or trying to work out why the one they already have isn't solving the problem in front of them. The short version: API gateways manage traffic to APIs that already exist. iPaaS connects systems together with workflows. If your problem is governing an API surface, you want a gateway. If your problem is moving data between SaaS products without writing glue code, you want iPaaS. If your problem is making your product reachable by AI agents, you want neither — but we'll get to that.

How API gateways work

An API gateway sits in front of one or more APIs and handles the operational concerns that don't belong in application code. Authentication, rate limiting, request routing, transformation, caching, logging. The API itself still has to exist — the gateway doesn't create endpoints, it manages traffic to endpoints you've already built. Kong, Apigee, AWS API Gateway, and Azure API Management are the canonical examples.

The gateway pattern became mainstream alongside microservices, though API management products predate that wave by years. Once you have twenty internal services, you don't want each one re-implementing OAuth, throttling, and observability. The gateway centralises that. It also gives platform teams a control plane: a single place to enforce policy, version APIs, deprecate endpoints, and observe traffic. For external API products — Stripe-style developer platforms — a gateway is non-negotiable. It's how you offer a stable contract to thousands of consumers without coupling every concern to your application code.

How iPaaS works

An integration platform as a service connects different SaaS products to each other through pre-built connectors and visual workflows. Workato, MuleSoft, Boomi, and Tray.io are the established names. The promise is that instead of writing custom code to sync Salesforce contacts to HubSpot, or push NetSuite invoices into a data warehouse, you drag connectors onto a canvas, map fields, and ship.

iPaaS earns its place when an organisation runs dozens of SaaS tools and needs data to move between them without an integration engineer in the loop for every new flow. The connectors abstract the underlying APIs — credentials, pagination, rate limits, retries — and the workflow engine handles scheduling, branching, and error handling. The trade-off is what you'd expect: you depend on the platform's connector coverage, and anything outside that coverage means either custom code inside the platform or a separate integration entirely. The architecture is point-to-point at the surface and hub-and-spoke underneath, with the iPaaS acting as the hub.

How they compare

The table makes the categories look cleanly separated. In practice teams often run both — a gateway for the APIs they publish, an iPaaS for the SaaS-to-SaaS plumbing they don't want to own. The mistake is asking either one to do the other's job.

When to choose an API gateway

Reach for an API gateway when the API surface is yours and you need to operate it at scale. Specifically:

• You're publishing APIs externally and need authentication, rate limiting, and quota management as first-class concerns.
• You're running enough internal services that centralising cross-cutting policy is cheaper than duplicating it.
• You have a versioning and deprecation story to manage — see our guide on API versioning and deprecation when agents are the consumer for what's changing here.
• You need a control plane for observability, audit, and policy enforcement across an API portfolio.
• You're building a developer portal and want a single place to enforce the contract you publish. Our practical guide to building a developer portal covers the rest of the picture.

The gateway doesn't make your API more capable. It makes the API you have operable. If the underlying surface doesn't expose what you need, no gateway in the world will fix that.

When to choose an iPaaS

Reach for an iPaaS when the integration problem is system-to-system, the systems are SaaS, and the value is in workflow automation rather than capability creation. Specifically:

• You're moving data between SaaS products on a schedule or event trigger.
• The connectors you need are in the vendor's library, and the operations you need are the ones the connector exposes.
• The work is structured enough to be expressed as a workflow — branching, mapping, retries — and stable enough to justify the configuration time.
• Non-engineering teams need to own and modify the integrations after launch.
• You'd rather pay for connector maintenance than do it yourself. For why that line item matters more than teams expect, see our piece on connector maintenance cost.

iPaaS struggles when the integration requires capabilities the connector doesn't expose, when latency matters in the single-digit-millisecond range, or when the workflow needs to execute as a specific authenticated user rather than a shared service account. Those constraints don't disqualify iPaaS, but they're where the architecture starts working against you.

When neither one fits

There's a third situation worth naming, because it's where most agent projects in established SaaS companies are stalling right now. You're not trying to govern an API surface. You're not trying to sync Salesforce to HubSpot. You're trying to make your own product reachable by AI agents — and the APIs you built for human developers don't cover what your product can actually do.

A gateway can't help, because there's nothing on the other side of it. The capability your agent needs doesn't exist as an endpoint. An iPaaS can't help either, because iPaaS connects third-party systems into your product — it's pointed the wrong way. What you need is a tools layer: something that generates agent-callable tools from the code paths your UI already uses, runs them as the authenticated user, and maintains them as your product changes. We dig into that distinction in embedded iPaaS vs the tools layer and SaaS integration in the agent era.

The practical test: if you can describe what your agent needs to do, and there's no API endpoint that does it, neither category in this comparison is your answer.

What we'd choose

If the question is genuinely API gateway vs iPaaS, the decision is structural, not preferential. Choose by which side of the boundary you're operating on.

You're publishing or operating APIs you own — gateway. The gateway is infrastructure for an API product. It doesn't make sense without one.

You're stitching SaaS systems together with workflows — iPaaS. The iPaaS earns its keep when the integration count crosses the threshold where bespoke code stops paying back, and when the people maintaining the flows aren't full-time engineers.

You're running a portfolio with both problems — both. They're not substitutes. A gateway in front of your published APIs and an iPaaS for system-to-system flows is a common, sensible architecture. The two don't overlap as much as the marketing suggests.

You're trying to unblock an agent project — step back. The structural problem in established SaaS isn't gateway policy or workflow plumbing. It's that the product's internal surface is invisible to agents because the API never kept up with what the UI can do. Picking the wrong category here doesn't just waste budget. It hides the problem for another quarter.

The useful question isn't "gateway or iPaaS." It's "what's on the other side of this thing, and is that what my agents actually need to reach?" Once you can answer that, the category usually picks itself.