Every Shopify-to-NetSuite project hits the same question in week one: should sync run in real time, or on a schedule? The honest answer is that the right choice depends on three numbers — order volume, inventory turnover, and your NetSuite governance budget — and most teams pick the wrong option because they only look at one of them. Here is the framework we use to decide, with the cost ranges and break-even points worked out.
Who this is for: commerce leaders and integration architects choosing a Shopify ↔ NetSuite sync architecture for a store doing $1M+ ARR. Below that volume, the cost difference is small enough that you should just pick whichever your integration vendor defaults to.
What “real-time” and “scheduled” actually mean
Real-time sync, in practice, means event-driven: a Shopify webhook fires when an order is placed, an inventory level changes, or a customer record is updated, and your integration pushes the change to NetSuite within seconds. Scheduled sync means a job runs every N minutes, queries Shopify for changes since the last run, and batches them into NetSuite. The trade-off is latency on one side versus governance and reliability on the other.
“Real-time” is a marketing word more than a technical one. In production, an event-driven sync with retries averages 5–30 seconds end-to-end. A 15-minute scheduled sync averages 7.5 minutes of staleness. For most flows, that gap doesn’t matter; for two specific flows, it does.
The two flows where latency genuinely matters
Inventory available-to-sell
If you sell a SKU on both Shopify and a wholesale channel (or two Shopify stores), and the SKU has low stock, the latency between “wholesale order ships in NetSuite” and “Shopify shows the new available quantity” is the window in which you’ll oversell. At 15-minute polling, oversells happen multiple times per week on any SKU with fewer than 20 units. At 5-minute polling, oversells drop sharply. At webhook-driven, they’re rare enough to handle through customer support rather than process redesign.
Fraud-suspected order holds
If your warehouse picks orders within 30 minutes of the NetSuite sales order being created, you need the Shopify “fraud risk: high” signal to land in NetSuite before the order moves to the pick queue. A 15-minute scheduled sync means a meaningful percentage of high-risk orders ship before the hold can be applied. Webhook-driven is the only architecture that closes this gap.
For literally every other flow — order creation for fulfillment, customer record updates, fulfillment status pushed back to Shopify, financial reconciliation — a 15-minute scheduled sync is functionally indistinguishable from real-time in customer-perceived behaviour.
The governance cost nobody talks about
NetSuite governance units are the real budget constraint on a high-volume sync. Every record read, write, search, and transform consumes units, and a webhook-driven architecture that fires per-event is dramatically less efficient than a scheduled batch that fetches 100 orders in one search and writes them in a queued chain of saved searches.
Concrete numbers from a recent project at ~2,000 orders/day: the webhook-driven architecture was burning roughly 4× the daily governance budget of an equivalent 15-minute scheduled job, mostly because each webhook spun up its own RESTlet context with its own setup overhead. At the 5,000 orders/day threshold, that 4× delta starts pushing against NetSuite’s per-day governance ceiling — you end up either upgrading the SuiteCloud Plus license tier or batching the webhooks anyway, which puts you back in scheduled-sync territory with extra steps.
The decision framework
- Under 500 orders/day, single sales channel, no fraud-screening urgency: 15-minute scheduled sync. Cheapest to build, cheapest to run, no measurable customer impact.
- 500 – 2,000 orders/day, multi-channel inventory: hybrid. Scheduled sync for orders, customers, and fulfillment status. Webhook-driven for inventory only. This is the architecture we ship most often.
- 2,000+ orders/day, multi-channel, fraud holds matter: webhook-driven for orders and inventory, scheduled batch for everything else, and a SuiteCloud Plus license budgeted in.
- Flash sales or scheduled drops: webhook-driven inventory regardless of overall volume. The first hour of a drop will oversell anything on a scheduled sync, full stop.
The cost ranges to budget for
For a typical mid-market implementation in 2026: a 15-minute scheduled sync runs at a one-time build cost in the low five figures and a monthly operating cost dominated by the SuiteScript governance allocation already covered by your existing NetSuite license. A webhook-driven sync at comparable scope costs roughly 2–3× to build (more error handling, more retry logic, more idempotency work) and may add a five-figure annual line item for additional NetSuite governance capacity above 2,000 orders/day.
The hybrid pattern lands between the two on build cost and below the webhook-only architecture on operating cost, because the high-volume flows (orders, customers, fulfillment status) are still batched. This is why we default to hybrid for stores in the 500–2,000 orders/day band — it captures the inventory accuracy benefit without paying the full governance bill.
What this means for the build
Architectural choices should follow the numbers, not the marketing. If your integration vendor pitches webhook-driven as universally superior, ask them to model the NetSuite governance load at your projected 12-month order volume. If your existing scheduled sync is causing inventory pain on specific SKUs, the answer is rarely “rebuild everything as real-time” — it’s almost always “add a webhook listener for the inventory events only, leave the rest of the sync alone.”
If you’re scoping a new build right now, decide the architecture on the volumes you’ll have in 18 months, not the volumes you have today. The cost of switching from scheduled to hybrid is moderate. The cost of switching from full webhook-driven back to hybrid because you’ve blown the governance budget is significantly higher, because you’re rewriting under operational pressure.
FAQ
What about NetSuite’s native Shopify connector?
The native connector is scheduled-sync architecture under the hood, with configurable intervals. It’s a reasonable starting point for stores under 1,000 orders/day. Above that, most teams hit either flexibility limits (no custom field mapping past a certain point) or volume limits, and migrate to a custom or third-party integration.
How do I handle webhook delivery failures?
Shopify retries failed webhooks with exponential backoff for up to 48 hours, but you should never rely on that alone. Always pair webhook-driven sync with a daily reconciliation job that compares Shopify order IDs against NetSuite for the last 48 hours and replays anything missing. Without the reconciliation job, you will lose orders — not many, but the ones you lose will be the ones the customer notices.
Does this apply to Shopify Plus B2B?
The framework is the same, but B2B order volume tends to be lower and per-order revenue much higher, so latency requirements relax and accuracy requirements tighten. Most B2B Shopify Plus stores run fine on a 15-minute scheduled sync, with a webhook listener on the company-record and price-list endpoints where staleness is unacceptable.