What is iPaaS? Integration platform as a service, explained

iPaaS in two sentences

An iPaaS is a hosted integration platform: the vendor runs the servers, the scheduler, the queues and the logs, and you build flows on it that move data between your applications. A flow is a trigger followed by a list of steps, each step reading from or writing to one application through a prebuilt connection.

The four parts every iPaaS has:

The split in the third column is the main thing to know about iPaaS. The platform is a service. What runs on it is your work.

How an iPaaS flow runs

Take an order flow from Shopify to NetSuite. It starts on a schedule, every 15 minutes, or on a Shopify webhook. For each order it runs a fixed list of steps.

Written down, the flow is a definition like this one, simplified and in no particular vendor's format:

{
  "trigger": { "schedule": "every 15 minutes", "since": "last successful run" },
  "steps": [
    { "read":   "shopify.orders", "filter": "updated_at > since" },
    { "lookup": "netsuite.customer", "by": "email" },
    { "lookup": "netsuite.item", "by": "sku", "each": "lineItems" },
    { "create": "netsuite.salesOrder", "map": "order-to-salesorder" },
    { "update": "shopify.order.tags", "value": "ns-{tranid}" }
  ],
  "onError": "stop record, show in dashboard"
}

Every step is an API call. For an order with one line that is five calls; with three lines, the item lookup runs three times and it is seven. The calls go to Shopify and NetSuite under their limits, not the platform's.

The mapping sits in the map step, and it is where most of the work goes: which NetSuite customer belongs to an email, which tax code to a Shopify tax line, which location to a fulfillment. The platform provides the screen to write those rules in. Writing them is the same work on any platform; field mapping shows what it involves for one order.

How iPaaS usage is metered

Platforms count usage in one of three units: connected applications or endpoints, active flows, or executed steps (called tasks, operations or runs, depending on the vendor). The unit decides what makes the bill grow.

A worked example with step-based metering. A store with 300 orders a day, an average of 2 lines per order, and 3,000 stock changes a day:

A sale day with four times the orders adds 300 x 3 x 6 = 5,400 steps in one day. On endpoint or flow metering, the same volume counts as two connected applications and two flows, and a busy day changes nothing; a third application or a new flow does. Prices per unit differ per vendor and are on their own pricing pages.

Limits that stay the same on any platform

An iPaaS connects to Shopify and NetSuite like any other integration, so the limits of those systems apply unchanged, and they are shared across everything that uses the same connection or account.

Two worked examples of what sharing means.

Shopify: a stock flow that writes 3,000 changes one variant per call uses at least 3,000 x 10 = 30,000 points. At 100 points a second that is 300 seconds, five minutes in which the order flow on the same connection competes for the same budget and gets THROTTLED responses. Written in batches of 250 per inventorySetQuantities call, the same changes are 12 calls. The arithmetic per plan is on Shopify API rate limits.

NetSuite: six flows on a Standard account, each running two requests in parallel, want 12 concurrent requests. The account accepts 5. The other 7 are refused with a concurrency error and have to be retried, and the 3PL and the expense tool that use the same account wait in the same line. How to plan within that limit is on NetSuite concurrency limits.

iPaaS, connector or custom integration

An iPaaS is one of three ways to connect a store to an ERP. The others are a connector, a finished product for one pair of systems, and a custom integration, written for one business and run by the party that built it.

All three call the same APIs. The full comparison on throughput, pricing logic and failure behavior is in custom integration vs iPaaS.

What this means for your integration

An iPaaS gives you a runtime and a flow builder; the flows, the mapping, the retry rules and the upkeep stay with whoever builds them. We take that whole part: we build the integration to your systems and your rules, then host it, monitor every run and change it when a source changes. Orders go through a queue with retries, so a refused request waits instead of failing, and a record that fails the mapping lands on a review list with the reason.

What that looks like for a store and an ERP is on ecommerce ERP integration. Tell us which systems you connect today and how, and you get a fixed price for an integration that is built and run for you.