How to Build a Bulletproof Shopify ↔ NetSuite Integration

Before any code: list every entity that flows between the two systems, its direction, and which system is authoritative. One boss per entity; the other side gets a read-only copy.

1. List the entities: products/variants, inventory, pricing, customers, orders, fulfilments, refunds, returns, tax/shipping — with the sync direction for each.
2. Default that works for most brands: NetSuite owns items, pricing, inventory, customer master, and accounting; Shopify owns storefront, sessions, and order origination.
3. Document the exceptions explicitly — e.g. a negotiated B2B price on a Shopify Plus order is the system of record for that order, not the catalog.

The middleware layer is non-negotiable for production. Put a durable queue between Shopify and NetSuite so spikes and outages never drop an order.

1. Build an event-driven service whose job is to absorb spikes, retry with exponential backoff, de-duplicate webhook replays, and route events to the right RESTlet.
2. Authenticate to NetSuite with REST web services + OAuth 2.0 / token-based auth; never point Shopify webhooks straight at a RESTlet.
3. Configure a dead-letter queue: after N retries (5 is typical) a failed message parks there and pages an on-call engineer.

Orders are the highest-stakes flow. Verify the signature, acknowledge fast, and let a worker do the slow part.

1. Subscribe to orders/paid; verify the HMAC signature in the headers and reject anything that doesn’t match.
2. Enqueue the event and return 200 OK within 5 seconds (Shopify times out webhooks after 5s and marks them failed).
3. A worker calls a NetSuite RESTlet that runs the idempotency check (Step 4), resolves the customer, maps SKUs to item internal IDs, and creates the Sales Order.
4. On failure, the message returns to the queue for backed-off retry, then to the dead-letter queue.

The single rule that prevents duplicates: calling an endpoint twice with the same Shopify ID must produce the same result as calling it once.

1. Store the Shopify entity ID in an indexed custom field on the NetSuite record (custbody_shopify_order_id, custentity_shopify_customer_id).
2. Every RESTlet searches for an existing record with that ID before creating one; if found, return the existing internal ID as success — don’t throw, don’t duplicate.
3. Enforce the uniqueness in code at the search level (NetSuite doesn’t enforce DB uniqueness on custom fields).

The boring fix that prevents ~30% of first-week order failures: make Shopify variant SKUs and NetSuite items line up before you turn on order sync.

1. Run a reconciliation between every active Shopify variant SKU and every NetSuite item internal ID + name; resolve every mismatch first.
2. Pick one system as the SKU master (almost always NetSuite) and lock edits in the other side or sync them automatically.
3. Key sales-order lines on the NetSuite item internal ID, not the SKU string — internal IDs don’t change when an item is renamed.
4. Build an unmapped-item handler: hold the order in a review queue and alert finance instead of silently dropping or failing the whole sync.

Inventory flows NetSuite → Shopify in batches, not per-change. A scheduled Map/Reduce gathers deltas and bulk-updates Shopify, with a checkpoint.

1. Run a Map/Reduce script every 5–15 minutes that gathers inventory deltas since the last checkpoint and batches them to Shopify’s bulk endpoints.
2. Write a checkpoint timestamp on success so a failed run resumes from the last good point instead of replaying everything.
3. Never fire Shopify calls from a per-record User Event Script — a bulk adjustment of thousands of items will hit Shopify’s rate limits and crash.

Close the loop: when NetSuite (or the WMS/3PL) ships, push fulfilment and tracking to Shopify; route refunds and returns back with finance gates.

1. On Item Fulfillment, create the Shopify fulfilment with tracking against the correct fulfilment order and location.
2. Let Shopify own customer-facing shipping notifications; don’t duplicate them from NetSuite.
3. Flow refunds and cancellations Shopify → NetSuite behind a finance-approval gate; handle returns/RMAs as their own process.

Be honest about which flows need custom code. Most production stacks are a connector for the standard 80% plus custom code for the 20% that doesn’t fit.

1. Connector (Celigo, NetSuite Connector / FarApp, Boomi) when: under ~500 orders/day, simple SKUs, single store/subsidiary/location, B2C only, speed-to-live matters most.
2. Custom when: high or spiky volume, kits/bundles/configurable products, multi-store or multi-subsidiary routing, B2B negotiated pricing, or you need full control of retries and audit logs.
3. If you split 80/20, make the two halves aware of each other — shared SKU master, shared idempotency keys — or they’ll fight.

If a finance person can’t answer “did the last 24 hours sync cleanly?” from one screen, you’re not done. Surface failures; don’t bury them in logs.

1. Dashboard sync counts by status and end-to-end latency; alert on dead-letter depth and on SKU-reconciliation drift.
2. Give the dead-letter queue a one-click retry UI so a human can replay a fixed message — don’t make failures a code deploy.
3. Watch NetSuite governance (RESTlet and Map/Reduce usage units) and alert before you hit limits.
4. Avoid hardcoded location/subsidiary IDs — they break in Sandbox and the first time someone adds a fulfilment location. Replay last year’s peak before BFCM.