Shopify Integration: Choose the Right Method
Most Shopify integration projects go wrong before a line of code is written, at the moment someone decides how to connect the two systems. There are five ways to do it — a published app, Shopify Flow, middleware, a custom app on the Admin API, or webhooks into a small service of your own. They are not interchangeable, and they do not cost the same to own. The rule we work to: pick the cheapest method that can actually hold the shape of your data, and no cheaper.
Below is how each method behaves, the three questions that decide between them, and the limits that only show up after you are live.
The five ways to connect anything to Shopify
1. A published app from the App Store
Someone else already built and maintains the connection. You install, authorise, map a few fields, done. This is the right answer far more often than technical teams like to admit — if an app covers your case, building the same thing yourself means adopting a maintenance burden in exchange for nothing.
The catch is field mapping. Published apps assume a common data shape, and the moment your product data carries something unusual — a bundle that is one SKU in Shopify and four in your warehouse system, a price that varies by customer group — the app either drops it silently or refuses it loudly. Test with your real catalogue, not three sample products.
2. Shopify Flow
Flow is Shopify’s own automation layer: a trigger, some conditions, an action. Tag customers who order twice, hold orders over a value threshold for review, send an internal notification when inventory drops. It runs inside Shopify, costs nothing extra on the plans that include it, and a non-developer can maintain it.
Flow is not an integration tool in the strict sense — it moves data within Shopify and can call out via HTTP, but it does not reconcile two systems. Use it for rules and routing. Do not use it to keep a catalogue in sync.
3. Middleware (iPaaS)
A connector platform sits between Shopify and the other system, holds the field mapping, and retries failures. You are paying for someone else’s plumbing and error handling, which is genuinely worth money when you are connecting to an ERP or accounting system that nobody wants to write an adapter for twice.
It buys you speed at the cost of a recurring bill that scales with order volume, and a mapping layer that lives in a third party’s UI rather than in your repository. That second cost is the one teams underestimate — when the person who configured it leaves, the configuration is undocumented and invisible.
4. A custom app on the Admin API
You build against Shopify’s Admin API and run it yourself. Full control of the data shape, the sync schedule, and the error behaviour. This is the right answer when the mapping is genuinely specific to your business and no off-the-shelf connector models it. It is also the answer with the longest tail: you now own authentication, API version upgrades, rate limiting, logging, and someone being on call when it breaks at 2am.
5. Webhooks into a small service
Shopify pushes an event to your endpoint when something happens — order created, product updated, customer redacted. You react. This is the lightest custom option and the one we reach for most, because it avoids polling entirely: nothing runs until something actually changed.
The discipline it demands is that webhooks can arrive more than once, out of order, or not at all. A handler that assumes exactly-once delivery will eventually create a duplicate order. More on that below, because it is the single most common integration bug we are called in to fix.
How to choose a Shopify integration method
Does the data need to move both ways?
One-way is a feed. Two-way is a reconciliation problem, and it is an order of magnitude more work. If inventory is written by your warehouse system and by Shopify when an order is placed, you need a rule for which one wins when they disagree — because they will disagree. Name the system of record for every field before you choose a method. Many projects that “need” custom development turn out to need one-way sync plus a clear owner.
How often, and how fresh?
“Real time” is usually shorthand for “I have not thought about this.” Ask what breaks if the data is five minutes stale. For accounting exports, nightly is fine and simpler. For inventory on a store that oversells fast-moving lines, minutes matter and webhooks earn their keep. The freshness requirement, not the technology, should pick the method.
Who owns it in two years?
Every custom integration is a small piece of software with no product manager. Ask who upgrades it when Shopify’s API version rolls, who is paged when it fails silently, and whether that person still works here. If the honest answer is nobody, choose the published app or the middleware and accept the constraints — an integration that no one maintains fails eventually, and fails quietly.
The limits nobody mentions until you hit them
Rate limits are a design constraint, not an error. Shopify meters API access — the REST Admin API on a bucket-and-refill model, GraphQL on a calculated query cost. The practical consequence is the same either way: a migration or bulk sync that hammers the API will be throttled, so your client needs to back off and retry rather than treat a limit response as a failure. Check the current limits in Shopify’s own documentation for your plan and API version before you size a bulk job — they change, and a number copied from a blog post is worse than no number.
Webhook delivery is at-least-once. The same event can arrive twice. The fix is to make your handler idempotent: record the event ID you have already processed, and make a repeat a no-op. This is five lines of code written up front and a week of reconciling duplicate records written after launch.
Every integration is a performance decision too. Anything that injects script into the storefront is now part of your page weight, which is the mechanism behind most of what we cover in how an app stack quietly degrades store speed. Server-to-server integrations avoid this entirely — one more reason to prefer them where you have the choice.
| Method | Direction | Typical freshness | Who maintains it |
|---|---|---|---|
| Published app | Usually both ways, fixed mapping | App’s schedule | The app vendor |
| Shopify Flow | Within Shopify, can call out | Event-driven | Your ops team |
| Middleware / iPaaS | Both ways, configurable | Schedule or event | Platform + whoever configured it |
| Custom app (Admin API) | Whatever you build | Whatever you build | You, indefinitely |
| Webhooks + service | Shopify out, you call back in | Near-immediate | You, indefinitely |
What this looks like in practice
Most of what we deploy sits in the first two rungs of that ladder, deliberately. Payment gateways, reviews, loyalty, shipping and marketing tools are solved problems with maintained apps behind them — our Shopify integration guides document the configuration we actually ship for each one, and the full directory of apps we deploy lists what goes on a typical build. The Klaviyo setup guide is a good example of the pattern: a published app, but with the event and field mapping written down rather than left at defaults.
Custom work starts where the mapping stops being generic — an ERP with a bespoke product hierarchy, a B2B pricing rule that no app models, a fulfilment partner with its own protocol. That is what our integration services exist for, and the honest framing is that we try to talk clients out of it first. If you want the vocabulary before that conversation, API integration in our glossary covers the terms, and the Shopify Storefront API is a separate question again — that one is about your front end, not your back office.
Frequently asked questions
Do I need a custom app, or will an existing one do?
Start by testing an existing app against your real catalogue and your real edge cases. If it holds your data shape without silent drops, use it. Custom development is justified by a mapping that genuinely does not exist off the shelf — not by a preference for owning the code.
Is Shopify Flow enough to replace an integration?
For rules and routing inside Shopify, often yes. For keeping two systems agreeing about the same records, no — Flow does not reconcile state, and using it that way produces drift you will not notice until someone audits it.
Why did my integration create duplicate orders?
Almost always because a webhook was delivered more than once and the handler assumed it would not be. Store the event ID, check it before you act, and make a repeat delivery do nothing.
Does an integration slow my store down?
Only if it runs in the browser. Server-to-server integrations and webhooks add no page weight. Apps that inject storefront scripts do, and that cost compounds across an app stack — it is worth auditing what each one actually loads.
The takeaway
Shopify integration is a choice about ownership, not about technology. The five methods trade control against maintenance in a straight line, and the failure mode is almost always the same: a team picks a method further up that ladder than the problem required, and inherits a piece of unowned software. Name the system of record, decide how fresh the data really needs to be, work out who maintains it in two years — then pick the simplest method that survives all three answers.
Current store performance