API Integration Platforms, Compared: Three Products Sold Under One Word

“Which API integration platform is best” has no answer, because the question hides three different products that happen to share a name. A team asking it on a vendor call is usually one signature away from buying the wrong tier, and the way they find out is the invoice rather than the feature list.

We do not sell any of the platforms below. We get called in after the decision, usually when a bill has tripled or a workflow has charged a customer twice.

The three products are these. Internal ops automation is an ops person wiring their own tools together: Zapier, Make, Workato, Power Automate, Celigo, Tray. Embedded integrations are the ones your customers configure inside your product, so that their Salesforce talks to your SaaS: Merge, Paragon, Prismatic, Nango, Apideck, Cyclr, Alloy, Membrane. Enterprise system-to-system plumbing is the ESB-replacement lane where Boomi, MuleSoft and Informatica live. Underneath all three sits the baseline every buyer should price against: build it yourself on a durable-execution primitive, or on a queue and a worker.

Almost nothing that decides the outcome appears on a feature matrix. Nobody churns off an integration platform because the connector list was short. They churn because the bill scaled with a metric they never modelled, because a webhook retried and a customer got charged twice, or because a compliance review found the execution logs could not say what data moved. Those are the three arguments here, in that order.

Three products wear the same name

Start by naming the job. Everything downstream follows from it: what the bill scales with, what it costs to leave, and who owns the thing at 2am.

The enterprise plumbing lane is a fourth column we left out, because it assumes an org with a dedicated integration function. If you have one, you already know.

Discard one thing before comparing anything: the connector count. Zapier’s own blog post on this category says 6,000+ integrations while Zapier’s pricing page said 9,000+ in the same week. One company, two numbers, no methodology attached to either. Membrane claims 100,000+ against roughly 250 commonly attributed to Merge and 130+ to Paragon, which tells you the vendors have stopped counting the same thing — Membrane’s figure almost certainly reflects schema-driven API coverage rather than hand-built connectors. What matters is whether the eight connectors you need exist, are maintained, and expose the specific fields your product writes to.

Tier A: automating your own operations

Tier A is what most people mean by “integration platform,” and it is the tier least likely to be what an engineering team needs. The buyer is an ops or RevOps person. The artefact is a visual workflow in the vendor’s cloud, triggered by a webhook or a poll, chaining actions across apps that person already has credentials for.

These products differentiate on audience more than capability. Zapier and Make sell to the individual builder with a credit card; Workato and Tray to enterprise IT with a procurement process. Power Automate sells to whoever already bought Microsoft 365, with premium connectors like Salesforce and SAP sitting behind a higher plan than the standard Microsoft-stack ones. Celigo prices around endpoints and flows rather than per action, a genuinely different metric from its peers.

n8n straddles Tier A and Tier C: in the vendor’s cloud it is a Tier A product with a technical skin, self-hosted it is closer to Tier C infrastructure. That split matters more than any feature it ships.

Almost nobody in this tier publishes real prices above an entry tier. Zapier, Make and n8n do; Workato, Tray, Celigo, MuleSoft and Boomi (beyond a $99/month data-integration entry point) are all “contact sales.” The honest planning number for those is “expect five to six figures annually,” not any specific figure you will find on an aggregator site. Every dollar amount circulating for them comes from pricing-comparison sites that frequently cite each other, so four sources agreeing is not four confirmations.

And the pricing model itself moves under you. Workato shifted from recipe-based pricing, where a fixed number of recipes ran unlimited actions inside them, to consumption pricing billed per trigger and action — reportedly in early 2024, though no Workato-authored announcement states the date and both February and July circulate. It has since added a High-Volume Recipes SKU billed flat per recipe, a vendor solving a problem its own pricing model created. That problem is the next section.

The billing unit is the whole product

This is the part of the evaluation that decides whether a platform is cheap or ruinous, and it is almost never on the comparison page. Everything turns on the definition of one unit.

Zapier bills per task, and Zapier’s own help documentation defines a task as one successful action step, not one run of a Zap. That definition explains the entire genre of surprise-invoice stories. An eight-step Zap fanning out over 100 records consumes roughly 800 tasks in a single trigger; run it daily for a month and you are at 24,000. That is arithmetic, not an anecdote. We are deliberately not quoting the dollar figures that circulate alongside these stories, because each traces back to an aggregator retelling a forum post nobody has produced. The mechanic is documented. The horror stories are not.

What happens past the line is documented too. Zapier’s overage terms put you on pay-as-you-go at 1.25× the per-task rate on annual plans and 2.5× on monthly, capped around 3× the plan’s included tasks. The worst case is bounded, and the bound is three times what you budgeted.

Now compare that against vendors using the same English word to mean something else.

Look at rows two and three. n8n’s pricing page defines an execution as one run of the entire workflow regardless of node count, which is why its tiers (Starter €20/month for 2,500 executions, Pro €50/month for 10,000, Business €667/month for 40,000) look so unlike Zapier’s at comparable workloads. Inngest uses the same word to mean the opposite: the function run plus each step inside it, so a five-step function costs six executions. We could not confirm that from Inngest’s own pricing page, though it is consistent across every secondary source we checked — read it as reliable but unconfirmed. Two vendors, one word, inverted meaning, and no way to compare their price lists without reading both definitions first.

Temporal’s Cloud pricing sets the same trap in different vocabulary. An “Action” is not a workflow run: each Activity, each Timer, each Heartbeat counts separately. Temporal Cloud starts at $100/month including one million Actions, roughly $50 per million after that, which reads as generous until you estimate from workflow count and discover your Activity fan-out multiplies the total by an order of magnitude.

Since 2025 there is a second meter to model. Zapier Agents bills in “Activities”, a unit entirely separate from Zap tasks, free to 400 a month and $33.33/month for 1,500 on Pro. Make landed on the same structure independently: its own changelog confirms operations became “credits” at a 1:1 conversion, cosmetic for ordinary actions, then states that AI modules charge variable rates based on tokens, file size or pages processed, and that Make Code costs two credits per second of execution. Two vendors with different pricing philosophies arriving at the same design is the pattern worth naming: AI steps are a separate, usage-sensitive meter bolted onto the flat one.

So before you look at a price, write down your worst-case fan-out — the largest batch you will ever process, times the steps in your longest workflow, times the frequency — and ask the vendor to convert it into their unit. If they cannot do it on the call, that is the answer.

Tier B: integrations your customers configure

This is the tier most Series A SaaS teams actually need and the one they are least likely to have heard of. Your customer wants your product to read their HubSpot and write to their Salesforce. They click a button in your UI, authorise their own account, and expect it to work. From that moment someone holds an OAuth grant per customer per provider, and you own every failure mode downstream of it.

Three architectures compete for the job, and comparing them on a shared feature grid produces nonsense.

Unified APIs (Merge, Apideck) give you one normalised schema per category. Write against Merge’s HRIS object model once and every HRIS provider behind it appears the same. The cost is the schema itself.

Embedded iPaaS (Paragon, Prismatic, Cyclr, Alloy, Membrane) gives you a workflow builder plus a brandable connection UI you drop into your product. Your customer sees your integrations catalogue; the vendor runs the executions behind it. Prismatic is the one with a real data-residency story, offering private and GovCloud hosting at enterprise tier.

Auth and proxy (Nango) declines to normalise anything. It runs the OAuth dance, stores and refreshes tokens, and proxies your requests to the provider’s actual API with the provider’s actual schema. You write more code and you keep every provider-specific field.

Pricing diverges hardest from Tier A here, because the unit is usually a connection rather than a call. Merge bills per linked account, reportedly $650/month for up to ten production linked accounts and $65/month for each one beyond. Those figures are consistent across independent write-ups but not confirmed on Merge’s own page, so treat them as directional. Run them against a real customer base and it gets interesting: 200 customers averaging three connections each is 600 linked accounts, landing near $39,000/month at those reported rates.

Cyclr publishes real numbers, which in this tier is unusual enough to name: $999/month for its MCP platform on shared infrastructure, $1,495/month for the shared service-embedded product, and native embedded from $1,595/month plus a charge per active connector. Nango publishes a free tier and per-connection overage rates. Almost everyone else does not — Paragon’s own pricing page lists two named tiers and a “get a quote” button against both, and Prismatic, Alloy and Membrane are the same. The absence is information. Your price is a function of your negotiating position and your disclosed customer count, and you cannot model this tier from a website.

One gap affects how you read any comparison of these vendors, this one included. Gartner published an iPaaS Magic Quadrant in March 2026 naming Boomi, Workato, SAP, Informatica and Salesforce/MuleSoft as Leaders, per the vendors’ own press releases about a report we have not read. No Tier B vendor appears in it, and we found no analyst coverage of the embedded category at all. Everything comparing Merge to Paragon to Nango is therefore vendor material or someone’s reasoning from public documentation.

Build versus buy, with the vendor numbers labelled

Every number in the build-versus-buy debate comes from a company selling the buy side. Some may well be right. Read them as evidence about what vendors claim.

Prismatic’s own build-vs-buy guide makes the most useful of these claims because it is structural rather than numerical: building the integration itself is “perhaps 20% of what is necessary,” with infrastructure, authentication, error handling and monitoring making up the rest. The same guide carries customer testimonials, including one company moving from 25% of engineering resources on integrations to zero — Prismatic’s customers, quoted by Prismatic, with no methodology and no audit. Paragon’s equivalent page leads with “ship native integrations 7x faster” against no stated baseline. Per Paragon’s marketing, unaudited.

The per-connector cost figures that circulate are weaker than vendor-sourced. You will find $8,000–12,000 and three to six engineer-weeks per connector, and 15–25% of build cost annually in maintenance. These appear near-verbatim across sites with no apparent relationship to each other, which is the signature of one uncredited original being copied rather than of independent corroboration. Use them as the range vendors claim, and keep them out of your business case.

The counterweight comes from inside the category, which is what makes it interesting. Unified.to, itself a unified-API vendor, argues against the unified-API premise: a pre-built normalised schema is by construction a lowest common denominator, and “core integrations almost always need custom fields, provider-specific endpoints, or per-customer logic that a fixed universal schema cannot express.” A vendor undercutting its own category’s pitch is the closest thing to a disinterested source here. Unified APIs are excellent for breadth over shallow objects, and they fight you the moment a customer needs the custom field their sales ops team added in 2019.

Then there is the fact nobody sells and everybody inherits. Whoever custodies your end customers’ OAuth grants owns your exit cost. If the vendor holds those tokens, switching vendors means every one of your customers performs a re-authentication, in your UI, prompted by your support team, at a moment you will have to explain. It follows from where the grant lives, which is why no vendor’s comparison page mentions it. Migrating off Zapier means rebuilding your own workflows, tedious and bounded. Migrating off a unified API is a customer-facing event.

The fairest argument for buying is about maintenance. Every connector is a standing commitment to watch a provider’s changelog and respond when pagination changes or the OAuth implementation rotates. At ten connectors that is defensible; at twenty it is a material fraction of engineering capacity producing nothing new. That framing comes from Truto, which sells against Merge, so it is vendor-adjacent, but it is mechanical rather than statistical and it survives contact with a spreadsheet. If you can see twenty connectors on your roadmap, buy. If you can see three, and one of them is most of the product, build.

Tier C: build it on a durable-execution primitive

Building means adopting a durable-execution engine: Temporal, Inngest, Trigger.dev, Windmill, and self-hosted n8n, a visual front end over the same idea. What they give you is retries and workflow state that survives a process restart.

Licensing is the first thing to check, because “open source” is doing heavy lifting in this category’s marketing. Temporal is MIT, Windmill’s community edition is AGPLv3, and Trigger.dev is Apache 2.0 by consistent report, though we have not opened the licence file ourselves. n8n is none of those: its LICENSE.md is the Sustainable Use License, source-available rather than OSI-approved, permitting internal business use and self-hosting for free while forbidding offering n8n itself as a hosted service to third parties. Nango is Elastic License 2.0, same broad category. For anyone whose product would resell the automation layer, that changes the decision entirely.

The self-hostable option is no longer the scrappy choice. In May 2026, SAP’s strategic investment doubled n8n’s valuation to $5.2B and put it inside SAP’s Joule Studio. A large enterprise vendor now builds on the thing you can run on a €6 VPS.

What you inherit when you build is a specific list, and it is the same list every time:

• Idempotency. Webhooks are at-least-once. You need a dedup key and a store that survives process restarts.
• Backoff and rate-limit handling, per provider, because their limits differ and most do not document burst behaviour.
• Token refresh with a lock. Concurrent refreshes are a real bug, covered below.
• Replay. After an outage you need to know what did not run, and to run it without re-running what did.
• Secret storage and rotation for one credential set per customer per provider.
• Log retention long enough to answer a compliance question, in a store you control.

A durable-execution engine gives you the first, the fourth and part of the second, and none of the rest. That is the honest scope of what “we’ll build it” buys: a team that priced only the workflow engine has priced about a third of the job.

Four things that break

Two of these are documented in detail by named engineers. Two are structural, and we will say which is which.

Duplicate writes are the best-evidenced failure mode in this whole category. A named engineer on n8n’s own community forum lays out the mechanism: webhook providers use at-least-once delivery, so a timeout produces a retry, and the retry runs the workflow again. The production symptoms named are duplicate Stripe charges and duplicate database writes. Worse, retries are not single-sourced — one arrives from the webhook provider, another from an HTTP client, sometimes a third from a queue worker. The fix required building a custom idempotency gate backed by Redis, because individual workflow executions have no memory across runs. Note what that proves about every platform here: the visual builder does not give you exactly-once, and it does not tell you it isn’t.

OAuth refresh races are the second. Paragon’s engineering blog describes it precisely: two workers refresh the same connection simultaneously, one overwrites the other, and you are left storing a refresh token the provider no longer accepts. The line worth keeping is that this class of bug “usually doesn’t show up in staging. It shows up at scale, under real concurrency, when cron syncs, retry logic, and a user clicking ‘sync now’ all fire against the same tenant.” Paragon sells a product that handles this, so read the framing accordingly; the technical description is checkable. The same post makes a point that generalises past the vendor: a token-store breach exposes every tenant whose tokens live in it, so the blast radius scales with your customer count rather than your architecture.

No review loop on visual workflows is the third, and the evidence for it is the existence of the workarounds. Third-party tooling exists specifically to retrofit git onto n8n, implementing the loop you already have for every other production artefact you own: export the workflow JSON, commit it, open a PR, run CI checks, promote to production. Here that is a bolt-on, which means the default state of a workflow platform is a production system where changes ship without review.

Execution logs are not audit logs is the fourth, and it surfaces late, in a security questionnaire or an incident. An execution log answers “did this workflow run, and did it succeed.” An audit log answers “what data moved, on whose authority, and why did the branch go that way.” Different artefacts, different retention requirements, different readers. A forty-connector sprawl of green ticks tells an incident responder nothing about which customer records left the building. Retention differs by tier too: Zapier’s execution logs run around 30 days on Business plans, while self-hosted n8n keeps whatever your own database keeps. Those figures come from comparison write-ups rather than vendor documentation, so check yours.

Two more failure modes get asserted constantly here, and we could not find a documented case for either: workflows failing silently with no alert, and drift between staging and production copies of the same workflow. Both are structurally plausible. Neither has a public incident behind it we can point to, so treat them as risks to test for rather than facts to plan around.

The compliance surface you just bought

The sharpest evidence in this whole category is a security disclosure. In February 2026, Token Security published an attack chain against Zapier they called “Zapocalypse”: a sandbox escape via os.system() in Code by Zapier, credential recovery from Lambda process memory through /proc/self/mem, lateral movement through an overpermissioned role, extraction of an NPM publish token from container build metadata, and finally supply-chain access to a design-system package loaded on zapier.com. Five stages, ending at attacker-controlled JavaScript in every authenticated Zapier session. The timeline was fast: discovered 10 February, reported 12 February, NPM token revoked by 16 February, remediated by 5 March, a $3,000 bounty paid at the program maximum.

Keep the researchers’ own limit on it. The chain would not have yielded raw OAuth tokens or API credentials for connected services, since those live server-side and never reach the browser. What it demonstrated is that the platform sitting between your systems is itself a target with its own supply chain and its own IAM mistakes, and that it is inside your boundary whether your vendor questionnaire modelled it that way or not.

The boundary question has a paperwork half that teams consistently underestimate. Every one of these platforms becomes a subprocessor under your own data-protection obligations. Merge’s own subprocessor page shows the mechanics: Merge maintains the list and commits to fifteen days’ advance notice of updates if you subscribe to its notification list. Tracking your own subprocessor chain is your obligation, and it is opt-in. Merge’s disclosed subprocessors include Amazon Aurora and Anthropic, so customer integration data may transit a model provider as well as cloud infrastructure — a disclosure you now owe your own customers.

This lands directly on audit scope. Adding an integration platform extends your vendor-management control and your subprocessor-disclosure obligations, ordinary work if you plan for it and an unpleasant surprise in month four of an observation window if you do not. We wrote up what SOC 2 actually costs a startup and how to keep the scope small, and the same line item dominates here: the hidden cost is internal engineering time, produced every year, indefinitely.

MCP did not change the business

By mid-2026, every vendor in this piece ships an MCP surface, and “ships MCP” means at least three structurally different things. Some expose their own action catalogue as an MCP server for third-party clients to call. Zapier MCP is the clearest example, alongside Paragon’s ActionKit MCP server and Merge’s Agent Handler. Some let their own agent consume external MCP servers as tools, which is what Make’s AI Agents do. Workato and n8n do both, n8n through an MCP Server Trigger node and an MCP Client Tool node that behave like any other node in the graph.

Every one of those surfaces sits on top of the connector catalogue rather than replacing it. The pitch behind a hosted MCP server is that the vendor already built and maintains hundreds or thousands of authenticated connectors, so you should point your MCP client at theirs instead of writing twenty one-off servers. MCP is an access method layered on the same managed-auth, retry and schema-mapping business these vendors were already selling. If you hoped the protocol would let you skip the platform, the vendors’ own product decisions say otherwise.

What MCP does not solve is unusually well established, because the people saying it compete with each other. Composio sells an MCP gateway and has every incentive to talk the protocol up, and it states plainly that “MCP is a valuable protocol that standardizes the syntax of tool calls… But it’s not a platform,” listing customer credential management, idempotency keys, retry logic and backoff as outside its scope. Truto’s Nachi Raman makes the same argument from the multi-tenant angle, pointing at the demo pattern of a stdio server reading credentials from environment variables at boot: “That works for a developer’s laptop. It collapses the moment your CRM agent needs to act on behalf of 4,000 distinct Salesforce instances.” Paragon publishes a version of the same list. Three vendors who sell against each other converging on what a technology cannot do carries more weight than any one of them alone.

Adoption is more modest than the press releases suggest. The figure quoted most often, 78% of enterprises running MCP in production, traces to no named survey, and we could not find an organisation willing to stand behind it. The credible number comes from Stacklok’s State of MCP in Software 2026: 41% of surveyed organisations in limited or broad production, with 50% still experimenting. That is 100 senior technical respondents surveyed in December 2025, published by a company selling MCP security tooling — small sample, interested publisher, disclosed methodology. It describes a technology mid-adoption.

Date any claim you make about the protocol, including the ones above. The MCP specification shipped a release candidate on 28 July 2026 adding authorization hardening, a stateless protocol core, Tasks for long-running work, and MCP Apps. “MCP does not handle auth” is accurate as of mid-2026 and has a visible expiry date on it. The auth-and-token business those vendors sell will outlast the gap, because the hard part was never the protocol.

What to do Monday

Name the job first. Write down which of the three you are buying for and check that your shortlist sells into it. Half the bad outcomes in this category are a Tier B problem solved with a Tier A tool because the ops team already had a licence.

Then take six questions into the demo.

What is the billing unit, exactly? Not the price, the unit. Make them convert your worst-case fan-out into their number on the call, and ask separately what an AI or agent step costs, because it is increasingly a second meter.

Who holds our end customers’ OAuth tokens? If the answer is the vendor, price a mandatory customer-facing re-authentication into your switching cost now, while it is still theoretical.

What is on your subprocessor list, and is notification opt-in? Read it before signing, and check whether a model provider is on it.

Does the log say what data moved and under whose authority, or only that the run succeeded? Ask to see a real one. A green tick per node is an execution log, and your auditor will want something else.

Who owns watch-duty when an upstream API changes? Get the answer in the contract rather than the sales deck. “We maintain the connectors” means something specific about response time, or it means nothing.

If we self-host, do we have idempotency and dedup? Answer that before the first webhook, not after the first refund.

The teams that get this right wrote their worst-case fan-out on a whiteboard, found out where their customers’ tokens would live, and only then opened a pricing page.

Naming the job costs nothing. Building the Tier C option does — our implementation engagement covers the durable-execution route for teams who have worked out that buying is the wrong answer.

References

• Zapier — How is task usage measured in Zapier
• Zapier — How pay-per-task billing works
• Zapier — How Zapier Agents usage is measured
• Zapier — pricing and Zapier MCP documentation
• Make — Introducing credits, the new billing unit
• n8n — pricing and LICENSE.md, the Sustainable Use License
• n8n community — Preventing duplicate webhook executions
• Temporal — Cloud pricing
• Cyclr — pricing
• Paragon — pricing, build vs buy, OAuth token refresh and expiry at scale
• Prismatic — build vs buy guide
• Unified.to — Building your own integration vs using a unified API
• Merge — data subprocessors
• Token Security — Zapocalypse: the attack chain that could have hijacked Zapier
• Composio — Is MCP enough for production-ready AI agent integrations?
• Truto — How to architect a multi-tenant MCP server for enterprise B2B SaaS
• Stacklok — State of MCP in Software 2026
• Model Context Protocol — 2026-07-28 release candidate
• Tech.eu — n8n’s valuation doubles to $5.2bn following SAP strategic investment