iPaaS Vendor Comparison: The Criteria That Survive the Sales Call

Every published list of iPaaS selection criteria contains the same five words: credibility, capability, security, usability, cost. They are not wrong and they are not usable, because every vendor scores well on all five when they are the ones answering.

A useful criterion is one where two vendors give visibly different answers and you can verify which is true. This post replaces the generic five with a set that has that property, aimed at someone actually running a selection rather than writing a slide about one.

First, decide what shape of problem you have
Connectors: the number is the least useful figure
The criteria vendors do not lead with
Pricing, modelled at your real volume
How this fits the rest of the stack
FAQ

First, decide what shape of problem you have

Integration platform covers products that are not substitutes for each other. Picking within the wrong category is the most expensive mistake available, and it happens before any comparison starts.

Business workflow automation. Connect SaaS products, move records, trigger notifications. Built for non-developers, priced per operation, hundreds of pre-built connectors.
Enterprise integration platforms. API management, data transformation at volume, orchestration across systems of record, governance and lineage. Built for integration teams, priced substantially higher, and capable of things the first category cannot approach.
Data pipeline tools. Move and transform data in bulk on a schedule for analytics. Different problem entirely, frequently confused with integration because both move data.
Developer-first automation. Workflows defined as code, in version control, deployed through CI. Suits teams who already have engineers and want integrations reviewed like other software.

Most selection processes that end badly compared products across two of these categories, weighting criteria that only matter in one. Write down which shape you have, in a sentence, before contacting anyone.

A useful test: if the people who will build the integrations are not engineers, you are in category one. If the integrations must be reviewed, versioned and deployed like software, you are in category four. If the answer is both, that is a real answer and it means two tools.

Connectors: the number is the least useful figure

Every vendor advertises a connector count. It is close to meaningless because the distribution is what matters, not the total. What you need is depth on the specific systems you actually use.

For each of your top five systems, check:

Does the connector cover the operations you need, or only the common ones? Reading records is universally supported; bulk operations, custom fields and less common endpoints frequently are not.
Does it support the triggers you need? Real-time webhooks versus polling on a schedule is a large functional difference. Polling with a fifteen-minute floor is not real-time no matter what the marketing says.
How does it authenticate, and what happens when that expires? OAuth refresh handled transparently versus a token someone re-enters every ninety days is a meaningful operational difference.
Who maintains it? A vendor-maintained connector gets updated when the upstream API changes. A community connector might not.
What happens when there is no connector? A generic HTTP node with proper authentication handling covers a great deal. A platform without one is limited to its catalogue.

A platform with two hundred connectors that are deep on your five systems beats one with two thousand that are shallow on them. Test this with a trial account against your actual systems rather than reading a matrix.

The criteria vendors do not lead with

These are where genuine differentiation lives, and where you should spend your questions.

Error handling and observability. When an integration fails at 2am, what exists? A searchable execution log with the payload, a retry policy you configure, alerting to a channel you watch, and the ability to replay a failed run after fixing the cause. This is the single biggest difference between platforms in day-to-day operation and it is almost never demonstrated.
Versioning and environments. Can a workflow be changed in a non-production environment, reviewed, and promoted? Or does editing the live workflow mean editing the live workflow? For anything business-critical this is a real requirement.
Idempotency support. Webhooks deliver at-least-once. If the platform has no built-in deduplication, every workflow that creates records is your problem to make safe.
Rate-limit handling. Does the platform respect upstream limits and back off, or will it hammer an API until you get blocked?
Data residency and processing location. Where does your data physically pass through, and is that acceptable contractually?
Export. Can workflow definitions be exported in a readable format? This determines whether migrating is a project or a rebuild.

Ask for a demonstration of a failed run being diagnosed and replayed. Vendors demo the happy path; the failure path is what you will spend your time in.

Pricing, modelled at your real volume

Pricing models in this space differ enough that a like-for-like comparison requires actual arithmetic rather than a plan-tier table.

Establish for each candidate:

What is the billable unit? A task, an operation, a step, an execution, a row, a connector, a user. A five-step workflow may cost one execution or five operations depending on the vendor, which is a 5x difference before any negotiation.
What happens at the limit? Overage billing, throttling, or hard stop. A hard stop mid-month on a business-critical integration is a very different risk from an overage charge.
Are polling triggers billed? A workflow polling every five minutes runs around 8,600 times a month whether or not anything happened. On per-execution pricing this is the entire bill.
What is the multi-year commitment, and what does the price do at renewal once you are dependent?

Model your top three workflows at expected volume against each vendor’s actual unit. This is an hour of work and it routinely changes the ranking, because the headline tier prices are constructed to be hard to compare and the unit definitions are where the difference hides.

One structural point worth weighing: per-operation pricing scales with your success. An integration that becomes central to the business becomes proportionally more expensive at exactly the moment it becomes hard to replace. Fixed-cost self-hosted alternatives invert that, at the cost of operating them — which is a legitimate trade, not a purity argument.

How this fits the rest of the stack

If the self-hosted option is on your shortlist, the comparison needs a real number for what running it costs: the tool, the database behind it, and the storage its execution history accumulates. The RunxBuild hosting calculator provides that side of the arithmetic. RunxBuild runs n8n as a managed tool — its own plan, custom domains, environment variables, autoscaling and logs — with managed Postgres alongside, which gives the fixed-cost profile without leaving you to operate the database and its backups.

Useful related references:

FAQ

What criteria should I use to compare iPaaS vendors?

Depth of connectors on your specific systems rather than total connector count, error handling and replay capability, versioning and environment support, idempotency, rate-limit behaviour, data residency, and export of workflow definitions. Generic criteria like credibility and ease of use do not differentiate because every vendor scores well on them.

Does the number of connectors matter?

Much less than the depth on your top five systems. Check whether each connector supports the specific operations and triggers you need, whether it uses real webhooks or polling, how authentication renewal is handled, and who maintains it. A platform with a good generic HTTP node covers most gaps.

How is iPaaS pricing usually structured?

By billable unit — task, operation, step, execution, row or user — and the definitions differ enough between vendors that a five-step workflow can cost one unit or five. Model your top three workflows at expected volume against each vendor’s actual unit before comparing tier prices.

Do polling triggers cost more than webhooks?

Usually much more on per-execution pricing. A workflow polling every five minutes runs roughly 8,600 times a month regardless of whether anything changed. Where a real webhook trigger is available, it is both cheaper and more responsive.

When should I self-host instead of buying an iPaaS?

When volume puts per-operation pricing well above the cost of running a service, when data cannot pass through a third party, or when you want workflow definitions in version control. The trade is that you operate the tool, its database and its backups — which a managed deployment of an open-source tool largely removes.