NetSuite + Shopify Integration Patterns That Actually Scale

NetSuite and Shopify are among the most common combinations in mid-market e-commerce: 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 → 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 → 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 — 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 → 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 → 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 — custom fulfillment logic, complex approval workflows, 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 → 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.