Integration Software: How to Choose the Right Kind

Integration software connects systems that were never designed to talk to each other. The category label covers at least four distinct shapes, and most bad purchases come from picking the wrong shape rather than the wrong vendor.

The four:

• Trigger-based SaaS automation — cloud services reacting to events. "When a deal closes, create the project."
• ETL / ELT — moving data in bulk on a schedule, usually into a warehouse for analysis.
• ESB / API management — governing many services talking to each other inside one organisation.
• Point-to-point — code you write connecting exactly two systems.

A note on iPaaS, because the term causes confusion: it's an umbrella, not one of these four. Vendors like MuleSoft sell iPaaS platforms spanning app, API and data integration, transformation and enterprise-scale workloads — so an iPaaS may cover the first three shapes at once. The lightweight trigger-based tools are also sold as iPaaS. The label tells you less than the shape does, which is why the rest of this article works in shapes.

Picking between them starts with one question: are you moving events or moving data?

Quick comparison

Point-to-point deserves more respect than it gets. For two systems and a stable requirement, a small, well-tested script is often cheaper and more reliable than a platform subscription. It stops scaling around the third integration, when you find yourself rebuilding retry logic and monitoring that a platform would have provided.

Events or data

The distinction that decides the shape:

Event integration reacts to something that just happened. A form submission, a closed deal, a new support ticket. Volume is low per event, latency matters, and the logic is usually "when X, do Y." Zapier, Make and n8n live here, and it's where most teams should start.

Data integration moves records in bulk so they can be analysed together — the territory of ETL tooling, and of the data-integration half of a full enterprise integration platform. Nightly syncs into a warehouse, replicating a production database for reporting. Latency is tolerable, volume is the constraint, and correctness across millions of rows is the hard part.

Using a lightweight trigger-based tool for bulk data is the more common mistake. Per-task pricing that's comfortable at 10,000 events a month becomes the dominant cost at 10 million rows, and the tool wasn't designed for that throughput anyway. This is the point at which an enterprise iPaaS earns its price — it's built for both shapes, which the trigger-based tools are not.

The questions that predict failure

"What happens when the target system is down?" Every integration eventually fires while something is unavailable. Retry policy, dead-letter handling and backoff are the difference between a delayed record and a lost one.

"How do we know it's still working?" Silent success and silent failure look identical from outside. An integration that stopped running four months ago is a genuinely common and expensive discovery.

"What happens on partial failure?" Half a multi-step flow completing is worse than none of it, because state is now inconsistent and nobody knows. Ask specifically how the tool handles a step failing mid-sequence.

"How do we test a change?" If the answer is "edit it in production," that's the real limitation regardless of the feature list.

"What's the cost at 10× volume?" Per-operation pricing is the most common source of budget surprise in this category.

The first three are about failure handling, which is where integration tools genuinely differ and where feature matrices are least useful.

Where the API doesn't exist

Some systems offer no programmatic access — older ERP installs, industry-specific software, internal tools nobody maintains. That's the one case for driving a user interface instead, and it's a maintenance commitment rather than a solution: a bot coupled to a screen layout breaks when the layout changes, silently, often at volume. The tradeoffs are covered in business process automation tools.

The rule holds firmly: use the API if there is one. UI automation is a workaround for systems that give you no other option.

What AI changes, and what it doesn't

Integration has always assumed structured data on both ends. The awkward cases were the ones where a human sat in the middle translating — reading an email to find the delivery date, deciding which category a free-text request belongs to, extracting fields from a supplier's PDF that looks nothing like the last supplier's.

That translation step is now automatable, which widens what counts as integrable. The discipline that keeps it safe is the same one in intelligent process automation: let the model interpret unstructured input into a structured shape, let deterministic integration logic move it. Keeping the model out of the execution path is what preserves your ability to debug a failed run.

The constraint to state plainly: an AI step returns a confident guess. For financial reconciliation, write a rule. For "which of these 300 emails mention a delay," a model is right tool, and a person should still see anything consequential.

The integrations nobody builds

Formal integration assumes a connection worth engineering — two systems, ongoing, owned by someone. Plenty of real work never clears that bar: pulling the relevant points out of a folder of PDFs into a spreadsheet, turning a week of scattered notes into a structured brief, running the same extraction every Monday against files that arrive by email.

Those are integrations in every meaningful sense. They just never justified a platform, so a person does them by hand indefinitely.

Someone has usually already built and shared the workflow. The reason it isn't running on your machine is that sharing means a repo, a runtime, environment variables and keys — the pattern in why most AI tools end up in your bookmarks. Taku is an AI-native desktop workspace built around that gap: mirror a workflow that already works for someone, run it against your own files without reassembling their environment, then remix it. The workflow library is the starting point. It's in Beta and it isn't integration software — for production system-to-system integration, use the tools above.

FAQ

What is integration software used for?

Connecting systems that don't natively talk to each other, so data or events move without someone re-keying them. The usual triggers are a new SaaS tool that needs to share data, or a manual copy-paste step somebody finally counted the cost of.

What's the difference between iPaaS and ETL?

They aren't opposites. ETL is a shape — moving records in bulk on a schedule, optimised for volume and correctness. iPaaS is a delivery model, and an enterprise iPaaS typically covers ETL-style data integration alongside app and API integration. The useful contrast is between trigger-based automation (individual events, low latency) and ETL (bulk records, scheduled); using either for the other's job produces cost or latency problems, whichever label the vendor uses.

Do I need integration software for just two systems?

Often not. A small, well-tested script can be cheaper and more reliable. The calculation changes around the third integration, when you start rebuilding retry, logging and monitoring that a platform provides.

How do I stop integrations breaking silently?

Monitor for absence, not just errors — alert when an expected run doesn't happen. Most silent failures are a job that stopped firing, not one that threw.

Can AI replace traditional integration tools?

No, and it shouldn't. Integration needs deterministic, auditable execution. AI is valuable at the edges, turning unstructured input into structured data the integration layer can move reliably.