Best iPaaS platforms: what you are actually buying
Integration platforms as a service are bought for governance rather than connectors. What separates them from workflow tools, how the main options differ, and when you do not need one.
Rebecca Pearson11 min read
On this page
Teams comparing iPaaS platforms against workflow automation tools usually conclude the iPaaS is worse value, because on connectors and ease of building it frequently is. That comparison misses what an iPaaS is sold for.
You are not buying the ability to connect two systems. You are buying environments, change control, audit trails, error queues you can replay, role-based access, and a support contract. Those are the things that make integration acceptable to an audit and survivable when it breaks at quarter end.
So the first question is whether you need that, because if you do not, the cheaper category is genuinely better.
What we'll cover
What separates iPaaS from a workflow tool
Five things, and none of them are about connecting apps.
Environments. Development, test and production as separate places, with a promotion path between them. Editing a live integration and hoping is normal on cheaper tools and unacceptable once an integration moves money.
Change control. Who changed what, when, with the ability to roll back. Asked routinely in audits and answered vaguely by most workflow tools.
Error queues with replay. When a record fails, it goes somewhere visible, and after you fix the cause you can reprocess it. Cheaper tools often log the failure and lose the record, which is fine for a notification and not for an order.
Role-based access. Which people may build, which may deploy, which may see the data passing through. A platform where every user is effectively an administrator cannot implement your policy however carefully you write it.
A support relationship. Someone whose answer is a commitment rather than a forum post, with a response time you have agreed.
If you read that list and none of it describes a problem you have, you want a workflow automation tool and you will be happier and considerably poorer off buying an iPaaS.
The pricing models, and why none are published
Workato, Celigo, Boomi, MuleSoft, SnapLogic and Jitterbit share a characteristic: no public price. You get a demo and a quote.
That tells you three things before any conversation.
The cost genuinely depends on your shape — how many systems, how many integrations, how much volume — so there is no single figure to publish. It also means the quote is negotiable in ways a published tier is not.
There is an implementation, usually months rather than weeks, frequently involving a partner. The subscription is often not the largest number in year one.
You are entering a relationship with renewal negotiations, which is an advantage when things go wrong and a commitment a nine-dollar plan does not ask of you.
The structures differ in ways worth asking about directly. Celigo states plainly that it charges flat-rate by endpoints and flows rather than per task or transaction, with no overage fees, which suits high volume across a stable set of systems. Workato prices around editions and workspaces with recipe lifecycle management, which suits many distinct automations across many teams. Get both to quote against your actual inventory rather than a description of your business, because the same estate can price very differently under the two models.
How the main platforms differ
Workato pushes hardest at automation being accessible beyond IT, with a recipe model intended to be readable by business users and a large community library. Where an organization genuinely supports that, it removes the central-team bottleneck. Where it does not, you have bought a platform pitched at business users that only IT operates.
Celigo leans toward prebuilt, packaged integrations for common pairings, particularly around NetSuite, Shopify and Salesforce, through its own marketplace. Closer to installing and configuring something proven than building from parts, which saves months on a common pairing and matters less if your systems are unusual.
Boomi is one of the longest-established, with broad enterprise coverage including on-premises systems, EDI and master data management. Strong where integration extends beyond SaaS into older infrastructure.
MuleSoft is API-led rather than integration-led: the emphasis is on building and governing reusable APIs across an organization, with integration as one outcome. Appropriate where the strategy is an API layer rather than point-to-point connections, and substantial in both cost and implementation.
SnapLogic and Jitterbit occupy similar ground with different emphases, SnapLogic on a visual pipeline model and Jitterbit on mid-market accessibility.
Tray sits between the categories, with more governance than a workflow tool and a lighter touch than the enterprise platforms.
The distinction that predicts fit better than any feature list: does your integration problem extend beyond SaaS into on-premises systems, EDI, or legacy databases? If yes, the older enterprise platforms earn their reputation. If everything is a modern SaaS API, the lighter options do the same work for less.
The capabilities that justify the cost
Worth testing rather than being told about, because every vendor will claim all of them.
Show me a failed record being replayed. Ask to see one fail in the demo environment and be reprocessed after a fix. How that looks is what you will live with, and it is the single most important operational property.
Show me the change history. Who edited what, when, and rolling one back.
Show me the promotion path. Building in development, testing, promoting to production. Ask what happens when two people promote conflicting changes.
Show me access control. A user who may build but not deploy. A user who may see that an integration ran but not the data inside it.
Show me the audit output. What a compliance reviewer would actually be handed.
If a platform handles those five well, it is an iPaaS. If it handles them vaguely, it is a workflow tool with enterprise pricing, and there are better workflow tools for less.
Embedded iPaaS, a different product
A separate purchase that shares the name and confuses comparisons.
Embedded iPaaS puts an integration platform inside your own software, so your customers connect their tools to your product without you building each integration. Albato, Paragon, Prismatic and others compete here, and so do some of the platforms above with separate offerings.
If that is what you want, the evaluation is entirely different: how the connections are branded, what your customers see, how authentication is handled, what happens when a connector breaks in front of a customer, and how it prices as your customer base grows. Very little of that has to do with automating your own operations.
When you do not need one
Fewer than twenty integrations and no formal compliance obligation. A workflow automation platform covers this comfortably at a fraction of the cost and with a fraction of the implementation.
Nobody has asked you the audit questions. If no one needs change history, environments and access control, you would be paying for capabilities that stay switched off.
Your integrations are all modern SaaS APIs. The enterprise platforms' distinctive strength is reaching beyond that, and you would be paying for reach you do not use.
The real constraint is who can build. This is the case most often mistaken for needing an iPaaS. If the problem is that processes wait in a queue because only a central team can build automations, a bigger platform for that team does not fix it — it formalises it. On CodeWords you describe a process in plain language and Cody, the automation builder, builds it, connects it to your systems, and deploys it, which puts building within reach of the person who owns the process. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Running an evaluation
Bring three real integrations, not a checklist: one simple, one with genuine transformation complexity, one touching a system you expect to be difficult. Build all three on each shortlisted platform.
Get quotes against the same written inventory so the numbers are comparable, and ask each vendor what the bill looks like at twice your current volume.
Involve security and audit early. They will have questions, and getting them at the end is how a preferred candidate gets rejected after everyone agreed.
Ask for a reference customer of your size and ask them who actually operates it day to day. That answer is frequently different from the pitch.
Ask what implementation costs and whether a partner is expected, including what happens to your integrations if that partner relationship ends.
Ask how you would get your integrations out. Not because you plan to leave, but because the answer tells you how much of what you build is portable and how much is the vendor's format.
Frequently asked questions
What is the difference between iPaaS and workflow automation?
Governance rather than capability. Both connect systems; an iPaaS adds environments, change control, replayable error queues, role-based access and a support contract. If those are requirements, the cheaper tools will eventually frustrate you. If they are not, you are paying for machinery you will not use.
Why does nobody publish pricing?
Because cost depends on the number of systems, integrations and volume, which varies too much for a tier list, and because the model is sales-led. The practical consequence is that the first quote is negotiable.
How long does implementation take?
Months rather than weeks for the enterprise platforms, longer if your systems are unusual or your data needs cleaning first. Prebuilt packaged integrations for a common pairing can compress that substantially, which is a large part of their value.
Do I need a partner?
Frequently, and it is worth asking what proportion of customers your size use one, what that adds, and what happens if the relationship ends. An estate built by a partner that you cannot maintain yourself is a genuine risk.
Can an iPaaS replace our ETL tooling?
Partly, and they are built for different shapes of work. iPaaS suits event-driven, record-level integration between applications. Data pipeline tools suit bulk movement into a warehouse for analysis. Organizations commonly run both.
What if we only have a few integrations?
Then an iPaaS is probably not the right purchase, and most vendors will say so if you are direct about your scale. A handful of integrations is better served by a workflow automation platform or by building them directly.
Is an iPaaS the answer to shadow integrations?
Only partly. Governance tooling helps once people are building on the platform, and it does nothing about the spreadsheet and the script on someone's laptop. The thing that actually reduces shadow work is making the sanctioned route fast enough that people stop going around it.
How do we stop the estate becoming unmanageable?
Ownership recorded as a field rather than remembered, a named owner per integration, and a review that actually removes things. Integration estates decay the same way in every organization: nobody deletes anything, and after three years a third of what runs serves a process that ended. The governance tooling helps only if somebody uses it to retire things as well as to build them.
Is it worth migrating existing integrations onto one?
Inventory them first, and expect a meaningful proportion to turn out unused — that discovery often justifies the exercise on its own. Migrate the low-consequence ones first so the team learns on work that can afford a mistake, run anything critical in parallel for a cycle, and set a date to switch the old ones off or you will pay for both indefinitely.