NetSuite and Shopify: the integration decisions that matter

The default split is the one most merchants reach: NetSuite owns the item master, cost, inventory and the financial record; Shopify owns storefront presentation, the customer’s account, and the order as it was placed. The arguments start at the edges, and the edges are where the money is.

Price is the first fight. Finance wants price to come from NetSuite because that is where margin lives. Marketing wants to run a weekend promotion without raising a ticket. Both are right, so split the object: NetSuite owns the base price, Shopify owns promotional pricing through its own discount mechanics, and the integration never writes to a discount.

Product content is the second. Split the record by field — ERP owns SKU, weight, dimensions, cost and status; Shopify owns title, description, images and SEO fields. Be explicit, because a connector configured to sync "the product" will overwrite three months of copywriting with a line from the item master.

Customers are the third, and the most common mistake. A Shopify customer is a shopper; a NetSuite customer is often an accounting entity. They do not map one to one, and forcing them to produces duplicate records in NetSuite at a rate nobody anticipated. Push orders with the customer attached and let NetSuite match or create on its own terms.

This is the one technical decision here we would argue about, because getting it wrong produces a bug that looks like an integration fault and is actually a modelling fault.

Shopify tracks inventory in several named states per location. on_hand is documented as the total units physically stocked at a location; available is the number ready for sale, calculated by subtracting committed, reserved, damaged, safety_stock and quality_control from on_hand. Crucially, committed — units held by orders placed and not yet fulfilled — is managed by Shopify, and the Admin API does not let you adjust quantities in that state.

So an ERP pushing its own available figure into Shopify’s available is competing with arithmetic it cannot see. Unless its picture of committed stock is identical, every sync fights Shopify’s. You get a product that oversells, or one showing out of stock with units on the shelf, and the sync log says success every time.

The correct shape: the ERP owns the physical count, writes it to on_hand, and lets Shopify subtract what it has committed. Use inventorySetQuantities, which sets an explicit value and takes a changeFromQuantity field implementing compare-and-swap — if the current quantity does not match what you supply, the mutation fails with CHANGE_FROM_QUANTITY_STALE rather than overwriting somebody else’s change. Passing null to opt out is documented as the choice for when you are the source of truth, which on a store taking orders while you sync you are not.

Orders flow one way — Shopify to NetSuite — and the mechanism is webhooks. Three properties decide the design, and all three are in the documentation rather than in anyone’s assumptions. Delivery is at-least-once, so the same order will arrive twice at some point. Ordering is not guaranteed: Shopify states plainly that it does not guarantee ordering within a topic, or across topics for the same resource, and suggests sequencing events yourself from the X-Shopify-Triggered-At header or the payload timestamps. And delivery is not guaranteed at all — the same docs recommend a reconciliation job as a safeguard.

What that adds up to: verify the HMAC, write the raw payload to a queue, return 200, and do the NetSuite work in a worker. Calling NetSuite synchronously inside a handler fails under load, when volume is highest, because the handler takes as long as the slowest thing it talks to. Key idempotency on the order id plus the topic and return 200 on a repeat — a sales order created twice in NetSuite is a financial event somebody unpicks by hand.

Fulfilment goes back the other way, and should use fulfilment orders rather than writing fulfilments against the order. Shopify’s documentation is unambiguous: apps using the Order and Fulfillment objects to fulfil orders are a legacy workflow unsupported since API version 2022-07. A connector that still fulfils that way is telling you how actively it is maintained.

Three shapes of answer, and the deciding question is not cost. It is how often your requirements will change.

A packaged connector suits a model close to standard: one currency, one warehouse, orders in, items and stock out. You are buying somebody else’s answers to the five decisions, which is a bargain when you agree with them. Evaluate one by asking it to do the two unusual things your business does; if the answer is a custom script inside the connector, you have bought a bespoke integration with a licence fee attached.

An integration platform suits several systems rather than two, and a mapping that keeps changing. You get monitoring, replay, and transformation logic visible to somebody who is not a developer — worth more than it sounds on a five-year-old integration.

Bespoke middleware suits logic that is genuinely yours: allocation rules, a pricing model nobody else has, fulfilment decisions that consult a third system. We build these and will still talk you out of one if a platform fits, because the build is the cheap part and being the only people who can change it in year three is not.

What we would not do is put that logic inside a Shopify app or a NetSuite script. Both ends then know about each other, neither can be tested without the other, and replacing either means rewriting the lot.

• Shopify integrations and back-end work
• Shopify ERP and internal systems integration
• Webhooks, retries and the orders you never processed