API integration vs. integration platform: which should you choose?

Definitions: what exactly do we mean?

The terms "API integration", "integration platform" and "middleware" are used interchangeably in practice. For the remainder of this article we use the following definitions so that we can compare like with like.

API integration

A direct point-to-point integration between two software systems via their APIs. One system calls the API of the other; the intermediate infrastructure consists of a thin adapter or integration layer that you build and host yourself. We cover this type of integration in depth on the page smart API integrations.

Integration platform (iPaaS)

A central middleware layer, delivered as SaaS, that connects multiple systems through pre-built connectors. iPaaS stands for Integration Platform as a Service. Well-known names: Zapier, Make (formerly Integromat), Workato, Boomi, MuleSoft, Tray.io, SnapLogic and Frends. You buy a subscription and build flows in a visual editor or low-code environment.

Middleware (older term)

The term middleware is still used, particularly in enterprise contexts, for ESB-style products such as webMethods, TIBCO or Talend. Conceptually, an iPaaS sits in the same layer, but cloud-native. A classic ESB often lives on-premises, requires its own operations and has an in-house product team to maintain the logic; an iPaaS shifts that burden to a SaaS vendor. If you want to know more about when to have an integration layer built yourself, our page on building middleware covers the practical side, and goes into the trade-offs of building it yourself, going hybrid or going fully SaaS.

So what is "API management"?

For completeness: API management is a separate category of tooling (Kong, Apigee, AWS API Gateway, Azure API Management) that secures, throttles and documents your own APIs. It is not an integration layer in the sense of this article; it is the shield for your own APIs. An organisation can have API management, an iPaaS and custom integrations all at once, as they solve different problems.

When should you choose a direct API integration?

A direct API integration is generally the right choice when the scope is small, the logic is specific, or the requirements for performance, security and control are high. We most often see these patterns among teams that opt for custom development:

• A small number of systems. You connect two or three systems that work together in a fixed setup, such as an ERP and a webshop, or a CRM and a marketing automation tool. The number of flows stays manageable.
• A one-off technical integration. There is no roadmap of thirty integrations; one solid integration is enough, and it should simply keep working afterwards without someone having to tinker with it every time.
• Specific business logic. The integration needs to do more than map fields: you have rules around source of truth, conditional transformations or orchestration steps that a visual flow editor cannot handle.
• Performance and volume. You process hundreds or thousands of events per minute. iPaaS platforms charge per operation and can become expensive at peak volumes; a custom integration has a fixed running cost.
• Security requirement: no data via a third party. In regulated industries (healthcare, finance, government), the business owner sometimes explicitly wants customer data not to pass through an external SaaS. A custom integration on your own infrastructure avoids that.
• Limited budget for subscriptions. A one-off build budget is sometimes easier to justify than an ongoing iPaaS subscription that scales per user or per task.
• An in-house developer team is available. You have people who can take on maintenance, investigate log failures and roll out API version updates whenever SaaS vendors change their contracts.

In these scenarios, a custom integration is almost always technically more elegant and financially more favourable in the long term. The downside: you invest once in design and build, and you are responsible yourself for monitoring, retry strategy and API updates of the connected systems. The last point is often underestimated: a SaaS vendor may announce a breaking change to its API only a few months in advance, and you then need to schedule time to migrate your integration. If you want to work through this trade-off in detail for one specific integration, we have described our experience with point-to-point integrations on our smart API integrations page.

When should you choose an integration platform?

An iPaaS is preferable as soon as the number of integrations grows, or when non-developers need to be able to adjust flows. The typical triggers:

• Five or more systems. Above that number, point-to-point connections become exponentially more expensive to maintain. A central hub reduces the number of connections from O(n²) to O(n).
• Many different integrations over time. Marketing regularly adds a tool, finance switches invoicing software, and sales adopts a new enrichment vendor. An iPaaS makes connecting these inexpensive and quick.
• Non-developers need to adjust flows. An operations colleague who can add a field to a Zapier zap themselves saves a ticket a week. For business-owned automation, iPaaS is strong.
• Fast time-to-market. A proof of concept on an iPaaS can be running within a few working days, whereas a custom integration quickly requires several sprints.
• Lots of standard SaaS in the stack. Ready-made connectors are available for Salesforce, HubSpot, Slack, Stripe, Shopify, NetSuite and hundreds of other mainstream tools. You no longer build an API client; you choose a trigger and an action.
• Multi-tenant context. SaaS providers that need to deliver the same pattern to hundreds of customers can scale faster on an iPaaS foundation than with bespoke integration code per customer.

What you give up: vendor lock-in to the iPaaS platform, ongoing subscription costs and a ceiling on complexity. Whatever a visual flow editor cannot do often requires a "callout" to an external function, and then you are partly back in custom-build territory. An iPaaS also adds an extra link in your data path: outages on the platform's side affect all your flows at once, and debugging often happens through a vendor portal rather than your own logs. That is not a dealbreaker, but it is something to weigh explicitly in your architecture decision.

The hidden costs of an iPaaS

Besides the subscription, there are three cost items that are often missing from quotes: licences for premium connectors (Salesforce, NetSuite and SAP usually charge a surcharge), training for your operations team so they can read the flows, and designing your own "connector strategy" once several teams start building their own zaps. The latter is not a technical but a governance problem: without clear agreements, you end up with hundreds of undocumented flows that nobody dares to switch off.

Cost comparison: what shifts?

We deliberately leave out figures here, as they depend heavily on your scope, your provider and your volume. We can, however, set out the structure of the costs side by side so that you can run the numbers for your own scenario.

The break-even point is generally somewhere around five to ten integrations. Below that, a direct API integration is usually cheaper; above it, a platform pays off because the number of integrations grows faster than the subscription costs.

Three real-world scenarios

Scenario 1 — Mid-market: HubSpot + Shopify + Loket + Slack

A growing mid-market company wants to connect its lead flow, e-commerce, payroll administration and internal communications. Four mainstream SaaS products with good public connectors. Here, an iPaaS (Zapier, Make or n8n) is a logical starting point: quick to go live, low initial investment, and non-developers can adjust flows. As volumes grow, an upgrade to a mid-market iPaaS (Workato, Tray.io, Frends) can make sense. The real gains come not from the first integration but from the sixth or seventh: marketing wants to connect a review tool, finance wants to automate debtor management, and operations can build those integrations themselves without raising a developer ticket each time.

Scenario 2 — Enterprise: 50+ systems with complex business logic

A large organisation with a legacy ERP, its own data warehouse, several CRMs following a merger and strict audit requirements. This is where an enterprise iPaaS (MuleSoft, Boomi, SnapLogic) comes into view, possibly combined with an in-house integration platform layer. We have described this type of architecture on our page on enterprise software development: governance, observability and standard patterns carry more weight there than time-to-market.

Scenario 3 — Custom development: Bullhorn ↔ Exact with complex rules

A staffing company wants to connect its ATS (Bullhorn) to its accounting software (Exact). It sounds simple, but there is a thick layer of business logic in between: which field is the source of truth in a conflict, how do you handle contracts that are later reversed, what do you do with duplicate candidate records, and how do you process a correction entry when a previously invoiced week is reversed after all? Here an iPaaS loses out to a custom integration, because the business rules don't fit in a visual flow editor and because the audit trail the accountant wants to see has specific format requirements. This is exactly the kind of work where our experience with integrations between business systems makes the difference: the integration itself is not the real work; the business logic on top of it is.

A hybrid is usually the answer

In practice, we rarely see an organisation end up on a single model entirely. Most mature integration landscapes opt for a mix: an iPaaS for the bulk of standard flows, and custom API integrations for the specific cases where the iPaaS platform falls short.

• iPaaS for 70 to 80 per cent of standard flows. Lead routing, notifications, simple field syncs, escalations. Quick to build, easy to explain, inexpensive to maintain.
• Custom API integration for the 20 to 30 per cent that is specifically complex. Master data management, critical real-time flows, high-volume transactions or regulated data streams.
• In-house integration layer as orchestrator. A thin, in-house middleware layer above your iPaaS and your custom integrations that contains the business logic provides an audit trail and gives you an exit route should you ever want to switch iPaaS vendor.

This "best-of-both" model is not a compromise but a deliberate architectural choice. The crux lies in where you draw the line, and that line moves as your stack matures.

iPaaS market overview (brief and neutral)

The iPaaS market has grown considerably over the past ten years and is now segmented. A rough categorisation, without preference:

Low-end and no-code

• Zapier — market leader in long-tail connectors, ideal for proof-of-concept and business-owned automation.
• Make (formerly Integromat) — visually stronger than Zapier, well suited to more complex flows without developer skills.
• n8n — open-source, self-hostable alternative, popular with teams that want to keep control of their data.
• Pipedream — code-first with visual components, popular with developers who want to prototype quickly.

Mid-market

• Workato — strong in HR and finance, with advanced governance.
• Tray.io — flexible, with good API management.
• Frends — Finnish platform with a good position in the Netherlands and the DACH region, strong in its combination of low-code and pro-code.

Enterprise

• MuleSoft — part of Salesforce, strong in API management and governance.
• Boomi — pure-play iPaaS with a broad connector library.
• SnapLogic — strong in data integration and AI-augmented flow design.
• Software AG webMethods — a classic ESB legacy, popular in heavy industry and the public sector.
• Workato Enterprise — Workato's enterprise tier, with separate governance and compliance features.

ETL and reverse ETL (data layer)

• Fivetran — managed data pipelines into your warehouse.
• Airbyte — open-source variant, modular and self-hostable.
• Hightouch — reverse ETL: moving data from your warehouse back into operational tools.

This list is not exhaustive and changes quickly. Vendors merge, pricing models change and positions shift. What remains: the difference between "I want to connect two tools" and "I want an integration strategy for an entire organisation" is real, and the right vendor is rarely found in a different segment.

How we advise on the choice

For clients who ask us for advice on integration strategy, we usually work through six steps before making a recommendation. This typically takes place over several sprints, depending on the scope:

• Inventory of current and expected integrations. Which systems are in use now, which are on the roadmap, and which are being phased out? This step often surfaces a number of "shadow integrations" that nobody officially knows about, such as Excel exports someone emails every week.
• Volume calculation. How many events per minute does each integration process at peak and on average? This figure determines the cost model of iPaaS vendors.
• Compliance requirements. GDPR, sector-specific regulation (NEN 7510 for healthcare, DNB guidelines for finance), data residency, and any requirements around audit logging. An iPaaS vendor that does not host your data in the EU is ruled out directly for some organisations.
• Team capability assessment. Do you have an in-house development team that can build and maintain API integrations itself, or do you depend on a partner? For organisations without their own development capacity, iPaaS is almost always the starting point.
• Roadmap fit over three years. Which direction is the organisation heading in? An acquisition strategy means integrating many different stacks, which suits iPaaS well. A specialisation strategy built on deep vertical software is a better fit for custom development.
• Migration path for when an iPaaS becomes necessary later. If you start with custom integrations, it pays to build a thin abstraction layer early on, so you can later move to an iPaaS without touching your applications again.

The outcome is not one-size-fits-all advice. It is a reasoned choice that fits your organisation, your stack and your roadmap, and it explicitly draws on the six points above, so that in a few years you can still check why you chose option A or B. If you want to browse our wider knowledge base for related topics, you will find related articles on integration, architecture and software strategy on our knowledge base overview page.

Frequently Asked Questions

What is the concrete difference between API integration and an integration platform?

An API integration is a direct, often custom-built connection between two systems via their APIs. An integration platform (iPaaS) is a central SaaS layer that connects multiple systems through prebuilt connectors. The first is custom and single-purpose; the second is platform software on which you build your own flows.

Which iPaaS platforms are popular in the Netherlands?

In the Dutch mid-market we see Zapier and Make for lighter use cases, Workato and Tray.io for more serious business flows, and Frends gaining ground. In the enterprise context, MuleSoft, Boomi and SnapLogic dominate, with webMethods still strongly present in legacy environments. For data pipelines, Fivetran is the de facto choice in the Netherlands.

iPaaS subscription or custom build: which is cheaper?

Below five integrations, custom build is generally cheaper; above that, the balance tips towards iPaaS. The break-even point depends on your volume and maintenance costs, not just the initial budget. Calculate the subscription based on your peak volume rather than your average, as that is the most common calculation mistake.

Can a business without an in-house development team use an integration platform?

Yes, that is actually one of the strong points of iPaaS. Tools such as Zapier and Make are built for non-developers, and even mid-market platforms such as Workato deliver good results with an operations team that thinks well in flows. For more complex integrations, a partner or consultant is still recommended, even if you manage the flows yourself.

When should you migrate from iPaaS to a custom solution?

The typical triggers are: costs that get out of hand as volume grows, flows that become too complex for the visual editor, or a compliance requirement that rules out external processing. It is rarely a big-bang migration; usually a handful of critical flows move to custom development while the rest stays on iPaaS.

What about GDPR when using an iPaaS vendor?

Under GDPR, an iPaaS vendor is a processor, and you sign a data processing agreement. Important to check in advance: where the servers are located, which sub-processors are engaged, how long data is retained, and whether an EU-only tier is available. For special category personal data (healthcare, sensitive profiles), it is worth going through each data flow with a privacy officer to establish whether processing via an external SaaS fits within your record of processing activities at all.