What a shopify sage integration actually has to move

The first question asked in most discovery sessions is how often the systems will talk to each other. It is the wrong question, because a shopify sage integration is not one connection. It is typically five or six distinct flows, each with a different tolerance for delay, a different failure cost and a different volume profile. Treating them as a single scheduled job is what produces the familiar pattern of an overnight run that either takes four hours or falls over silently, and a finance team that discovers the problem at month end rather than on the morning it happened.

The flows that usually matter are orders and their payment detail moving from Shopify into Sage 200 as sales orders or invoices; stock levels moving from Sage 200 out to Shopify; product and price data moving out; refunds and credit notes moving in; customer records moving in one or both directions; and, for trade sellers, account balances or credit limits moving out so the storefront can behave correctly. Each has an obvious natural rhythm. Orders arrive irregularly throughout the day. Stock changes whenever a goods receipt is posted or a pick is confirmed. Price files change perhaps weekly.

Cadence should be derived from the business consequence of being stale, not from what the API happens to permit. If a stock figure is fifteen minutes out of date, the worst case is an oversell on a fast-moving line. If an order reaches Sage 200 four hours late, the worst case is usually a delayed despatch or a picking list printed without it. If a price file is a day late, someone sells at last month's price. Those are three very different numbers, and they should produce three very different designs.

It is also worth separating latency from frequency. A job that runs every five minutes but processes a queue that is forty minutes deep is not a five-minute integration. What the business experiences is end-to-end lag, measured from the event occurring in the source system to the record being visible and correct in the target. That is the figure to agree in writing, and the figure to monitor after go-live.

Setting cadence per flow rather than per project

Once the flows are separated, each one can be given a mechanism and a target lag. Shopify supports webhooks for order creation, order payment, fulfilment, refunds and product updates, which makes event-driven capture straightforward on that side. Sage 200 is a different proposition: it is a system of record with accounting periods, posting rules and, in the Professional edition, a database that may sit on-premise or in a hosted environment with its own maintenance windows. Reading from it on a schedule is usually fine. Writing into it needs to respect its own pace.

A workable default set, which we would then adjust during data mapping, looks like this.

  • Orders into Sage 200 — Webhook capture from Shopify into a durable queue, with a drain worker writing into Sage 200 every few minutes. Target end-to-end lag of under fifteen minutes during trading hours. The queue matters more than the interval: it is what lets you absorb a flash sale without dropping anything.
  • Stock out to Shopify — Polled from Sage 200 on a short interval, typically five to fifteen minutes, but pushed only as deltas. Send the full catalogue once daily as a reconciliation pass. Buffer rules should be applied in the integration layer, not in either endpoint.
  • Refunds and credit notes — Event-driven, but deliberately lagged. A refund raised in Shopify at 16:50 does not need to be in Sage 200 by 16:55. Batching these hourly reduces the number of partial-state cases where a refund arrives before the invoice it relates to.
  • Products and prices — Scheduled, usually nightly or on demand after a price review. Real time here creates risk rather than value, because a mistyped price in Sage 200 reaches the storefront before anyone has checked it.
  • Customers and account data — Daily for consumer trade, more frequently where trade accounts and credit limits drive storefront behaviour. If credit limits gate checkout, this flow needs the same treatment as stock.

Where real time stops paying for itself

There are three practical constraints that pull a shopify sage integration away from continuous synchronisation, and all three should be raised before scope is fixed rather than discovered during build.

The first is write throughput into Sage 200. Creating a sales order with several lines, allocating stock and posting to the nominal ledger is a materially heavier operation than reading a customer record. On a busy day a store taking a few thousand orders is asking the ERP to absorb sustained write pressure at the same time as the finance and warehouse teams are using it interactively. Spreading those writes across a controlled queue, with a concurrency ceiling you have actually measured, protects the ERP from becoming unusable at four in the afternoon. It also makes the load predictable, which matters if Sage 200 is hosted alongside other workloads.

The second is the accounting calendar. Sage 200 posts into defined periods, and periods get closed. An integration that writes continuously will, sooner or later, try to post a transaction dated into a period that finance has just locked, usually during the first working days of the month. The design needs an explicit answer: hold the transaction and alert, re-date it under a documented rule, or route it to an exception queue for manual release. Whichever is chosen, it should be written into the specification and demonstrated during acceptance testing, because the alternative is a silent failure discovered in a VAT return.

The third is ordering. Events in Shopify have a natural sequence — order created, order paid, order fulfilled, order refunded — and if the integration processes them in parallel it will occasionally apply them out of order. A refund arriving before its invoice, or a fulfilment before its order, produces records that look corrupt but are simply early. Serialising by order reference, so that all events for a given order are handled by one worker in sequence, removes most of this class of defect at the cost of a little throughput. That trade is almost always worth making.

Designing the catch-up path before the outage happens

Cadence design is really failure design. The interval you choose determines how much work accumulates when something breaks, and how long it takes to clear once the fault is fixed. If Sage 200 is unavailable for a two-hour maintenance window on a Sunday evening, a store taking two hundred orders an hour has four hundred orders waiting. If the drain worker processes twenty orders a minute, it clears in twenty minutes. If it processes two a minute, it clears in over three hours and the Monday picking list is wrong. Both of those numbers should be established with measurement during build, not estimated afterwards.

Two mechanisms carry most of the load here. The first is a durable queue between the systems, so that Shopify webhook deliveries are acknowledged and stored even when the ERP is down. Webhook delivery is retried by the platform, but only for a limited window, and relying on those retries as your only safety net is a fragile position. The second is a watermark — a stored timestamp or cursor per flow that records exactly how far the last successful run reached — so that a polled flow can resume from where it stopped rather than reprocessing a fixed lookback window and hoping duplicate protection catches the overlap.

Catch-up should also be rate-limited independently of normal running. A backlog drain that runs flat out will consume Shopify's API allowance and starve the live flows that are still trying to operate. Shopify's cost-based limits on the GraphQL Admin API make this visible: a burst of catch-up work simply exhausts the available points and everything queues behind it. Giving the catch-up worker a lower concurrency ceiling than the live worker, and having it back off when the ERP response times rise, keeps recovery orderly.

Where a warehouse system sits in the middle, the same logic applies again. If Peoplevox holds despatch confirmations, the chain is Shopify to Sage 200 to Peoplevox and back, and the end-to-end lag is the sum of the slowest link in each direction. Adding a second sales channel such as Amazon Seller multiplies the stock-out flow rather than the order-in flow, because every channel needs the same availability figure at roughly the same time. That is an argument for a single stock service with one cadence, rather than per-channel jobs that drift apart.

Proving the cadence holds, and handing it over

A cadence that has only been tested with ten orders on a quiet Tuesday is an assumption. Acceptance testing should include a load profile that reflects the worst hour of the worst week — usually a promotional day or the run-up to Christmas — and should measure end-to-end lag at the ninety-fifth percentile rather than the average. Averages hide the orders that took forty minutes. It should also include a deliberate outage: stop the ERP connection for an agreed period, let the backlog build, restore it and time the recovery. If recovery takes longer than the outage, the design needs revisiting before go-live.

Ongoing, the integration should publish two numbers that operations and finance can see without asking anyone: current lag per flow, and count of items in the exception queue. Lag is the early warning. Exceptions are the work list. A daily reconciliation that compares order counts and order values in Shopify against what landed in Sage 200 for the previous day, and reports the difference, catches the quiet failures that monitoring alone misses — the order that was accepted, marked as processed and posted to the wrong nominal code.

Finally, the cadence decisions themselves belong in the handover documentation, with the reasoning attached. Someone will ask in eighteen months why stock syncs every ten minutes rather than every minute, and the answer needs to be recorded rather than reconstructed. Alongside the code, that documentation should state the target lag per flow, the measured throughput ceiling for writes into Sage 200, the behaviour when a period is closed, the retry and back-off policy, and the procedure for draining a backlog safely. That is the difference between an integration a business owns and one it merely operates.

None of this requires exotic tooling. It requires deciding, in writing and before code is written, how stale each piece of data is allowed to be, what happens when that promise cannot be met, and who finds out. Get those three answers straight and the cadence largely designs itself.

Key points

  • Cadence is a per-flow decision: orders, stock, refunds, prices and customer data each have a different cost of being stale and should be designed separately.
  • Write throughput into Sage 200, closed accounting periods and event ordering are the three constraints that most often make continuous synchronisation the wrong choice.
  • Size the recovery path before go-live — durable queues, per-flow watermarks and a rate-limited catch-up worker — and test it with a deliberate outage during acceptance.