Shopify ERP integration: what to sync, in which direction, and what breaks

Start with this table and change it with your operations and finance leads. An integration can’t resolve an argument about ownership, so settle it before anyone starts on the mapping.

Sources: GraphQL rate limits, API limits, bulk operations and access scopes. Limits are per app and store, and the page linked first explains how costs are calculated. Use the GraphQL Admin API for new work. Shopify has treated REST as legacy since October 2024, and new public apps have had to use GraphQL since April 2025.

The 60-day rule often catches people on a first sync. If you need older orders, request read_all_orders in addition to your order scope, and request it early.

Orders usually arrive through webhooks such as orders/create. Shopify’s webhook documentation gives you four rules to design around:

• Ordering isn’t guaranteed, within a topic or across topics. An update can arrive before its create, so compare timestamps and fetch the latest record when in doubt.
• Ignore repeats using the X-Shopify-Webhook-Id header, and store the order ID so processing twice does nothing.
• Verify the signature in X-Shopify-Hmac-Sha256 before you trust the body.
• Run reconciliation jobs, as Shopify recommends, to fetch data periodically. This job isn’t optional: it’s how you find what webhooks missed.

Accept the webhook quickly, put it on a queue and do the real work there. An ERP that is slow or down for maintenance shouldn’t cause Shopify deliveries to fail, and a queue lets you hold orders until it is back.

A bulk query lets you export a large data set without hitting rate limits on the query itself, although your calls to start and poll it still count. The result is a JSON Lines file, so you can process it one line at a time without loading everything into memory. Subscribe to bulk_operations/finish and keep polling as a fallback, because Shopify says that delivery isn’t guaranteed. Download results promptly since the link expires after a week. For a nightly price or stock run, compare against what you last sent and push only the changes. A full push every night wastes your allowance and hides real problems among the noise.

The first architectural choice is whether Shopify and the ERP talk to each other through a small service of your own, or through whatever connector the ERP offers. For anything beyond a simple setup, we lean towards a thin service in the middle. It doesn’t need to be large. Its value is in holding the things neither system wants to hold.

A service in the middle holds the ID mapping between Shopify and the ERP, the queue, the failure list and the daily comparison. It also shields each side from the other’s changes. When you replace your ERP in five years, the storefront doesn’t have to know. If you go this way, keep it boring: no business rules that belong in the ERP, and no copy of data it doesn’t need.

Stock looks like a single number until you try to sync it. The ERP may hold on-hand, allocated and in-transit quantities per warehouse. Shopify shows what can be sold at each location. Someone has to define the formula. A common one is on-hand minus allocated minus a safety buffer, and the buffer is a business decision rather than a technical one.

The gap between a sale on Shopify and the ERP knowing about it can oversell your last unit, and the gap gets worse in a busy sale. Your options are to hold a buffer on fast-moving lines, to shorten the sync on those lines, or to accept some overselling and have a clear customer process for it. Also decide who wins if the two systems disagree. We would normally treat the ERP as the truth and run a periodic check that corrects Shopify and reports how far it had drifted, because the size of the drift tells you whether something is broken.

Don’t treat an order as “sent” or “not sent”. Give each one a small state in your service, so that staff can answer “where is this order?” without calling a developer.

Hold orders on purpose where risk checks matter. Sending every order to the warehouse the moment it arrives means staff can pick something you then cancel. A short delay for payment and fraud review costs little, and the ERP gets fewer corrections.

Three things can multiply the work, so raise them early. B2B: customer-specific prices, payment terms and company accounts have to be mapped, and the ERP usually holds them. Check what your Shopify plan supports before designing this. Markets: several currencies and price lists mean one SKU has several prices, so find out which system decides them, and how rounding works. Multiple stores: each store has its own API limits, webhooks and IDs. Keep a store column on every mapping from day one, even if you have only one store today.

The last of those deserves extra attention. Shopify and your ERP may not calculate tax or spread discounts across order lines in the same way, so totals can differ by small amounts. If the ERP recalculates, you will find differences you have to explain. A safer default is to send Shopify’s line-level amounts and tax as the record of what the customer paid, and to have the ERP accept them, with a small agreed tolerance and a report of exceptions. Ask your accountant, because this affects how the books are kept.

• A daily comparison. Orders in Shopify against orders in the ERP, for yesterday, with totals. Anything missing goes to a person.
• A screen for failures. The operations team should see what is stuck and press retry without opening a developer ticket.
• A named owner. Someone reads that screen every day.
• API version upgrades. Shopify’s Admin API is versioned, so put version updates on your calendar. An integration nobody updates eventually breaks on a date you didn’t choose.
• An owner for the app itself. Custom apps are now created in the Dev Dashboard. Make sure the store’s owner, not one contractor, controls that access.

Don’t switch everything on at once. Begin in one direction, with the lowest risk: send stock and prices to a development store and compare the results. Next, send orders from a development store into an ERP test company. When you go live, run old and new side by side for a short period and compare them every day, with someone from operations reading the comparison. Move fulfilment last, since it triggers emails to real customers. Agree a way back as well: if the sync misbehaves during a busy day, who stops it, and how do orders get processed in the meantime? Write that down before you need it.

1. Which ERP and version, and does it have a documented API? This is often the harder half of the project.
2. How many orders a day at peak, how many SKUs, and how many locations?
3. Are you B2C, B2B or both? Company accounts and customer-specific prices change the design.
4. How many Shopify stores or markets feed the one ERP?
5. Does the ERP need each order in real time, or would batches every few minutes do?
6. Who currently fixes mistakes, and how many do they fix a week? That number helps justify the budget.

If you are also planning a move onto Shopify, do the mapping at the same time. See our migration checklist. Custom discount or delivery rules are covered in Shopify Functions now that Scripts have gone, and our wider approach is on the integration services page.