What is iPaaS? Integration platform as a service explained

The plain definition

Integration platform as a service is exactly what the name says: the integration layer of your stack, delivered as a hosted product instead of code you maintain. You pick a source and a destination, map fields between their schemas, add transforms where the shapes disagree, and the platform runs the sync on a schedule or on webhooks, with retries and logs included.

The category grew out of enterprise middleware (ESBs like TIBCO and BizTalk) but moved to the cloud and dropped the six-month implementation. A modern ipaas platform is self-serve: the first working sync should take minutes, not a statement of work.

What iPaaS replaces

Every team that reaches 4 or 5 SaaS systems accumulates the same inventory:

• A cron job on a forgotten EC2 box that copies Shopify orders into the ERP, written by someone who left in 2024.
• A Lambda function that pushes Salesforce contacts to HubSpot and fails silently when either API changes a field.
• A Zapier account whose per-task bill tripled the month order volume doubled.
• A weekly CSV export that one ops person uploads by hand, correctly, most weeks.

Each of these is a point-to-point link with an owner, a failure mode, and no monitoring. We wrote up why that inventory degrades so predictably in point to point integration problems; the short version is that the link count grows quadratically while your attention does not.

What is actually inside an iPaaS

Component	What it does	What it replaces
Connectors	Handle each API's auth, pagination, and rate limits	Hand-rolled API clients, token-refresh crons
Mapping layer	Declares which source field lands in which destination field	Field assignments scattered through script code
Transforms	Cents to dollars, date formats, name splits, enum mapping	The utils.py nobody wants to touch
Triggers	Webhooks and schedules, hourly down to every minute	Crontab entries and queue glue
Monitoring	Retries with backoff, alerting, per-record logs	Nothing. This is the part scripts never get.

The connector is the load-bearing piece: it is a productized API adapter, and the quality gap between platforms mostly lives there. A shallow connector gives you triggers; a production-grade one gives you idempotent retries, respected rate-limit windows, and a schema that updates when the vendor's API does.

When it pays off

The arithmetic is not subtle. An in-house integration costs 2 to 6 engineering weeks to build, and the industry rule of thumb for keeping one alive is about 20% of an engineer's time: schema changes, expired credentials, API deprecations, and the occasional 3 a.m. replay. At a loaded cost of $110 an hour, that maintenance tail is roughly $35,000 a year, per integration.

A platform subscription runs $49 to $399 a month. The break-even is typically 2 to 3 maintained integrations, before counting the incidents that never happen: the missed invoices, the stale CRM segments, the weekend orders that used to vanish.

How to evaluate one

Connector counts are marketing. Ask these instead:

• What happens when a record fails? You want automatic retries with backoff, an alert, and the exact payload in a log. Silent drops are disqualifying.
• Can you see data before it moves? A JSON-in, JSON-out preview on real sample records catches mapping mistakes before they land in your books.
• How is it priced? Per-task pricing punishes success: double the order volume, double the bill. Flat tiers keep the cost a line item instead of a variable.
• Two-way or trigger-action only? Automation tools fire actions; an integration platform keeps two systems agreeing over time, which needs dedupe keys and idempotency.
• Security posture: encryption in transit and at rest, scoped credentials, and no retention of synced records after delivery.

What adoption actually looks like

Teams expecting an enterprise-middleware rollout are usually surprised by how little ceremony a modern platform involves. A typical first week:

• Hour one: connect the two systems with scoped credentials, accept the auto-mapped fields that match (customer.email to Customer.Email style pairs), and rewire the three or four that do not.
• Day one: run the mapping against sample records, read the JSON in and JSON out, fix the two transforms that looked right and were not, and go live on an hourly schedule.
• Week one: tighten the schedule, wire alerts into the channel the team actually reads, and migrate the second integration, the one whose author left last year.

The pattern that works is strangler-style: move the riskiest script first, run it in parallel for a few days, compare outputs, then delete the cron entry. Big-bang migrations of all fifteen links at once fail for the same reason all big-bang migrations fail.

Where iPaaS is the wrong tool

Honest boundaries: if you need one warehouse pipeline and nothing else, a dedicated ELT vendor is fine. If you need to orchestrate human approval steps, you want a workflow engine. And a genuinely bespoke integration, embedded in your product with custom UX, may still deserve engineers. For the connective tissue between the systems you already run, a data integration platform is the difference between owning plumbing and renting it, maintained, monitored, and priced flat.