Integration platforms compared: Zapier, Make, n8n, Workato and Tray

The integration platform category is old enough that every entrant has the same headline features: hundreds of connectors, a visual builder, triggers, scheduling, error handling. Comparing on that list produces a tie.

The differences that matter are structural — where the thing runs, how it prices, what happens when you outgrow the visual builder, and who in the organisation is expected to operate it. This is a survey of five well-established options, not a ranking. Each has deployments at serious scale. Specific features and pricing change frequently; treat everything here as a starting point for your own evaluation rather than a current fact sheet.

Zapier

The category's default, and the one non-technical users reach for. The model is deliberately linear: a trigger fires, a sequence of actions runs. Its connector catalogue is the largest in the category by a wide margin, which for many teams settles the question — if you need a connector for something obscure, it probably exists here first.

The linearity is both the appeal and the ceiling. Simple automations are genuinely simple to build, and nobody needs training. Complex ones — branching, iteration over collections, error recovery — are possible but fight the grain. Pricing is task-based, which is predictable at low volume and can become the dominant cost at high volume, particularly for workflows that fan out.

Best suited to: business teams automating across SaaS tools, where breadth of connectors and low barrier to entry outweigh sophistication.

Make

Visually the most expressive of the group. Where Zapier shows a list, Make shows a graph — branches, merges, iterators and aggregators as first-class visual elements. For workflows with real branching logic, people who think spatially often find it clearer than a linear builder or a code file.

That expressiveness comes with a learning curve steeper than Zapier's, and the metering differs: Make counts credits — a unit it renamed from "operations" in 2026, so older comparisons use the other word — where a standard module execution costs one and heavier AI or code steps cost more. Loop iterations each consume a credit, so workflows that iterate over large collections consume them quickly, and the cost model rewards thinking about volume up front.

Best suited to: teams whose automations have genuine branching and data transformation, who want that visible rather than buried in code steps.

n8n

The notable property is that you can self-host it. For teams with data residency requirements, air-gapped environments, or a strong preference for owning the runtime, this narrows the field immediately — most of the category is SaaS-only.

The model sits between visual and code: a node graph where any node can drop into JavaScript, which tends to suit engineers who want a builder without hitting a wall. Self-hosting means you operate it: upgrades, scaling, availability, backups. A cloud offering exists for teams who want the model without the operations.

Worth noting its licence is source-available with commercial restrictions rather than a standard OSI open-source licence — if licensing matters to your organisation, read the current terms rather than assuming.

Best suited to: engineering teams that want control over where automation runs, and are willing to run infrastructure to get it.

Workato

Positioned at the enterprise end, and the differences show up in governance rather than in the builder. Environment separation, role-based access control, approval workflows for changes, audit logging, and the administrative apparatus large organisations need to let many teams build automations without chaos.

It's also the one most likely to be bought by a central platform team and offered internally as a service. Pricing reflects the segment — typically an annual contract rather than a credit card — and evaluating it usually means a procurement process. For a five-person startup that's friction; for a company with compliance obligations and forty teams, it's the point.

Best suited to: larger organisations that need governance and central administration as much as they need the connectors.

Tray

Similar enterprise positioning to Workato, with more emphasis on flexibility in the builder and on embedding automation into a product you ship to your own customers. The embedded use case — offering your users integrations under your own branding — is a distinct problem from internal automation, and Tray is among the options that take it seriously.

Best suited to: product teams building customer-facing integrations, and enterprises that prefer a more developer-flavoured builder.

What usually decides it

Who builds the automations? Non-technical staff: Zapier, or Make with some training. Engineers: n8n or Tray.

Where must it run? If self-hosting is a requirement rather than a preference, n8n is the obvious candidate in this group.

What shape is the logic? Linear sequences: any of them. Heavy branching and iteration: Make and n8n handle it more naturally.

How many people build, and who governs? A handful with informal review: the self-serve options. Dozens across departments with audit requirements: Workato and Tray exist for this.

What does volume cost? Model your actual expected volume against each pricing scheme before deciding. Task, operation and connector-based pricing diverge sharply at scale, and the cheapest option at 1,000 runs a month is frequently not the cheapest at 100,000.

The caveat worth more than the comparison

Teams usually migrate between these tools not because they picked wrong, but because of things none of the marketing pages discuss: no version control, no way to test a change before it affects production, no environment separation, and no visibility into why a run failed three weeks ago.

Evaluate those explicitly. They determine whether you can still maintain the system after two years and four hundred automations, and they're much harder to retrofit than a missing connector.