NetSuite + Shopify Integration Patterns That Actually Scale

NetSuite and Shopify are among the most common combinations in mid market ecommerce: Shopify for the storefront and customer experience, NetSuite for ERP, inventory management, and financial operations. The integration between them is critical, and it's where many organizations run into serious problems at scale.

The architecture of a NetSuite Shopify integration looks straightforward on paper, but what works at 50 orders a day breaks at 10,000. Here's what the architecture has to look like to survive real production load.

The Data Flows You're Connecting

A complete NetSuite Shopify integration handles five primary data flows:

Shopify to NetSuite:

1. Orders (new orders create NetSuite sales orders)
2. Customers (new/updated customer records sync to NetSuite)
3. Refunds (credit memos in NetSuite)
4. Fulfillments (shipping events from 3PL)

NetSuite to Shopify: 5. Inventory (real time or near real time inventory level sync) 6. Products (optional: product master managed in NetSuite) 7. Pricing (optional: price lists managed in NetSuite)

Architecture Pattern: Event Driven with Queue

The most common architecture mistake: polling based sync. A scheduled job runs every 15 minutes, queries Shopify for new orders, creates NetSuite records. This pattern fails in several ways:

• Latency: A 15 minute sync window means orders are "missing" in NetSuite for up to 15 minutes, which is problematic for high velocity fulfillment operations
• Volume spikes: A flash sale generates 500 orders in 2 minutes. Your polling job now has to process a backlog and can't keep up
• Failure handling: If the job fails mid run, you don't know which records were processed and which weren't

The correct pattern: event driven, queue based.

Shopify Webhooks to Queue

Shopify fires webhooks for every order, customer, refund, and fulfillment event. Instead of consuming these directly and writing to NetSuite synchronously, write them to a durable message queue (AWS SQS, Azure Service Bus, or Google Pub/Sub).

The queue provides:

• Durability: Messages persist until processed, even if your processing service is down
• Decoupling: Shopify fires the webhook and doesn't wait for NetSuite to respond
• Throughput buffering: 500 flash sale orders queue up and process at the rate NetSuite can handle them

Queue to NetSuite Processing Service

A processing service consumes messages from the queue and writes to NetSuite via the SuiteScript REST API or SuiteTalk SOAP APIs.

Key design decisions:

Idempotency: Every operation must be idempotent. If a message is processed twice (a queue delivery guarantee), the result should be the same as processing it once. Use the Shopify order ID as the NetSuite external ID to detect duplicate processing.

Retry logic: NetSuite API calls fail. Authentication tokens expire, rate limits are hit, the system is in maintenance. Implement exponential backoff retry (1s, 2s, 4s, 8s...) with a dead letter queue for messages that fail after N retries.

Error isolation: A single malformed order should not block the processing of subsequent orders. Errors go to the dead letter queue for manual review; the main queue continues processing.

NetSuite Specific Considerations

SuiteScript vs. REST API

NetSuite offers two integration paths: SuiteScript (server side scripts that run inside NetSuite) and the REST API (external API calls to NetSuite from your integration service).

For new integrations, use the REST API. It's better documented, more predictable, and doesn't require deploying code inside NetSuite's environment.

SuiteScript is appropriate when you need to perform logic that's deeply integrated with NetSuite's internal workflows, such as custom fulfillment logic, complex approval workflows, or advanced field calculations.

Rate Limits

NetSuite's REST API has concurrency limits based on your license tier. The limit is concurrent connections, not requests per second, but practically, you'll hit it during high order volume periods.

Implement a connection pool in your processing service that respects the concurrency limit. Use the queue's concurrency settings to limit parallel processing.

Financial Reconciliation

Order sync is the beginning, not the end. Shopify Payouts need to reconcile against NetSuite transactions for accurate financial reporting.

The pattern: download Shopify Payout reports daily via the Shopify Payments API, match each payout to its constituent orders, create NetSuite journal entries for the gross amount, fees, and net deposit.

This reconciliation is manual intensive without automation and critical for accurate financial reporting. Build it into the initial integration scope. Retrofitting it later is painful.

Inventory Sync Architecture

Inventory sync in the NetSuite to Shopify direction is different from order sync: it's not event driven (NetSuite doesn't fire webhooks), and it requires near real time accuracy during active selling.

The pattern that works at scale:

1. NetSuite inventory updates trigger an internal saved search or SuiteScript script that writes inventory change events to an external queue
2. Your processing service consumes inventory change events and calls Shopify's Inventory API
3. Sync frequency: near real time for active SKUs, bulk reconciliation nightly for full catalog accuracy

A common shortcut, syncing all inventory every 15 minutes via a full catalog export, doesn't scale past a few thousand SKUs and creates unnecessary API load on both systems.