Native connector, iPaaS or custom API: choosing a Shopify integration route

Every Shopify integration conversation arrives as the same question wearing different clothes: should we use the connector, buy middleware, or build it. The honest answer is that all three are correct for different stores, and the decision is arithmetic you can do in an afternoon.

Start from the flows, not the technology

Write down what must sync, in which direction, and how fresh it must be. Orders out, inventory back, customers both ways, prices on change. Most stores need four to six flows. The list is shorter than clients expect, and writing it down kills half the scope anxiety before any vendor call.

Then mark each flow standard or custom. Standard means the field mapping is obvious and the rules are vanilla. Custom means your business does something the mapping cannot express: location aggregation rules, price lists per customer group, transformation between systems that disagree about what a product is.

The three routes, honestly

Native connectors are the vendor's own integration or a marketplace app. They are the cheapest and fastest route, they cover standard flows well, and their limit is that you cannot change them. Error visibility is usually a badge, not a diagnosis. Use them when the flows are standard, volume is moderate, and nobody has to babysit the sync.

iPaaS (Celigo, Boomi, Zapier at the simple end) is managed middleware: prebuilt connectors, visual mapping, monitoring and queues without owning a codebase. Subscriptions scale with records and connections. Use it when you are connecting several systems quickly, your team prefers configuration to code, and the logic stays inside what the platform can express.

Custom API builds are a small service that speaks Shopify webhooks and your target system, with your rules, your queue and your reconciliation. Highest day one cost, lowest long run cost at volume, fully yours. Use it when logic is custom, volume is high, or control matters more than speed to first sync.

The three year cost curve

Model each route against your real volumes:

• Native: low upfront, low ongoing, fixed ceiling
• iPaaS: medium upfront, subscription scaling with volume
• Custom: high upfront, hosting only, curves flatten

The crossover between iPaaS and custom lands in year two or three for most stores doing meaningful volume. Below it, the subscription wins. Above it, you are renting infrastructure you could own.

The failure modes nobody demos

Connectors fail quietly: a red badge, a missing record, an email nobody reads. Whatever route you choose, insist on three things. Retries with a dead letter list that names the record and reason. Daily reconciliation that compares both systems and reports mismatches. And a runbook that tells your ops team what to do when the alert fires.

Those three requirements are why we build custom more often than the pure cost curves suggest: they are easy to promise in a custom codebase and hard to retrofit into someone else's connector. But if your connector already has all three, keep it, and spend the budget on something that grows revenue.

The decision, compressed

1. Standard flows, moderate volume: native connector
2. Many systems, fast, configuration over code: iPaaS
3. Custom logic, high volume, control: custom build
4. Any route, no retries and reconciliation: not finished

The audit exists to do this arithmetic with your numbers, in writing, before anyone commits. If an integration partner will not show you the three year curves, they are selling a route, not a solution.