ERPNext ↔ Shopify Integration - replay-safe commerce sync
Orders, customers, inventory, and fulfillment status synchronized with idempotency, evidence trails, and operational controls. Designed to survive failure - not to ‘usually work’.
Why Shopify-ERP integrations usually fail in production
The hard part is not syncing once. The hard part is staying correct after retries, webhooks, partial failures, and conflicting edits.
Most integrations treat retries as a ‘try again’. In commerce, that creates duplicate orders, duplicate customers, duplicate stock moves, and reconciliation chaos.
- Webhooks can be delivered more than once - duplicates happen unless you design for it.
- Jobs can crash mid-way - partial writes cause drift unless you can safely replay.
- Retry without idempotency is a correctness bug, not a feature.
Without explicit mapping rules and guardrails, one side slowly becomes ‘truth’ by accident, and teams stop trusting the data.
- Inventory directionality is often unclear and becomes a source of conflict.
- Edits made in one system get overwritten by late webhooks (‘echo’ effects).
- Failures hide in background jobs - teams only discover issues when customers complain.
Make it replay-safe, observable, and provable
This integration is engineered as an operational system. Every sync is traceable, every retry is safe, and failures are visible with controlled actions.
Webhooks and queued jobs are processed with deterministic keys and “already applied” checks, so replay does not create duplicates.
Every inbound/outbound action records what was received/sent, what was changed, and the final status - for audits and debugging.
Failures are not buried in logs. They are surfaced, categorized, and made actionable with safe retry/requeue controls.
What syncs (and how we keep it correct)
We intentionally avoid vague “it syncs everything” claims. These are the rails that keep commerce operable.
Orders are created/updated in ERPNext with replay-safe mapping. Each order update is tracked as an event with status and evidence.
- Replay-safe order creation/updates (no duplicates on re-delivery).
- State mapping rules (paid, fulfilled, refunded, canceled) are explicit - not guessed.
- Failure logs are attached to the exact order + event that caused them.
Customers are linked using stable identifiers and sync logs, so “same customer” remains the same customer even after retries and edits.
- Deterministic mapping to avoid duplicate Customer/Contact creation.
- Update rules that prevent overwriting ERPNext authoritative fields silently.
- Full event trail for each customer change.
Inventory is where most integrations go to die. We enforce directionality rules, echo protection, and safe mapping across locations.
- Clear directionality: outbound stock changes are tied to ERPNext events (e.g. deliveries, reconciliations).
- Echo protection: ignore Shopify webhooks triggered by our own recent outbound pushes.
- Location mapping rules so the right quantity updates the right place.
A production integration needs an operator interface: what failed, why it failed, what is safe to retry, and what should never be retried.
- Failure categories with actionable context (not raw tracebacks).
- Retry/requeue controls designed to be replay-safe.
- Evidence logs per webhook/event for investigations and audits.
Hard truths we handle explicitly
These are common production issues that the integration treats as first-class problems, not edge cases.
Stock movement in ERPNext can require valuation rules. We design the flow so your inventory stays correct without breaking posting.
Webhooks are verified to ensure requests are genuinely from Shopify before any changes are applied.
Queue floods and API limits are handled with rate limiting and safe job design, so failures don’t cascade.
How we implement without breaking your store
Commerce systems don’t tolerate ‘big bang’ changes. We roll out with guardrails, staged sync, and verification.
We set directionality rules, location mapping, identifiers, and evidence logging before turning on live sync.
- Connect Shopify + verify webhook authenticity.
- Define authoritative sources per field (Shopify vs ERPNext).
- Set up location mapping and product linking rules.
Turn on live traffic with dashboards, alerts, and controlled retries so teams can operate it confidently.
- Enable order/customer flows with replay-safe processing.
- Enable inventory flow with echo protection and guardrails.
- Expose failures with safe operator actions (retry/requeue).
Frequently asked questions
Straight answers to the questions we hear most about this integration.
Orders, customers, inventory levels, and fulfilment status are the core rails. Shopify orders create or update sales documents in ERPNext, customers are linked with stable identifiers, stock quantities are reconciled across locations, and fulfilment or shipping status flows so both systems agree. Every one of these is processed as a tracked event with its own status and evidence log, not a fire-and-forget push.
Overselling happens when the online storefront and the back office disagree on available quantity. The integration enforces clear directionality rules so stock changes originate from ERPNext events (deliveries, reconciliations, receipts) and are pushed to Shopify, while echo protection ignores the Shopify webhooks triggered by those same pushes. Because updates are ordered and replay-safe, the storefront reflects real availability instead of drifting behind fulfilment.
Idempotent means processing the same message twice produces the same result as processing it once. Shopify can deliver a webhook more than once, and a background job can crash mid-write, so the integration uses deterministic keys and 'already applied' checks to detect a repeat and skip it. Replay-safe means a failed or partial sync can be re-run from stored evidence without creating duplicate orders, duplicate customers, or double stock moves. This is what keeps the data correct under real-world retries rather than only on the happy path.
It is bidirectional but direction is defined per field, not left ambiguous. Orders, customers, and fulfilment typically flow from Shopify into ERPNext, while inventory and pricing are usually authoritative in ERPNext and pushed out to Shopify. Setting the authoritative source for each field up front is exactly what prevents late webhooks from overwriting back-office truth by accident.
Order state changes such as paid, fulfilled, refunded, and canceled are mapped with explicit rules rather than guessed. When Shopify records a refund or cancellation, the matching ERPNext document is updated to the correct state and any stock or accounting effect follows your configured rules. Because each state transition is tied to the exact order and event, refunds and cancellations stay traceable and reconcilable instead of silently diverging.
Yes. Location mapping rules connect each Shopify location to the correct ERPNext warehouse so the right quantity updates the right place, and the same mapping approach extends to multiple stores feeding one ERPNext instance. Stock, orders, and fulfilment stay correctly attributed per location and per store, which matters once you run more than one warehouse or storefront.
Related insights
Plain-language guides on why systems should integrate and how retail commerce sync works.
What disconnected storefronts, stock, and accounting really cost, and how integration fixes it.
How to choose a retail system that keeps stores, stock, and the back office in sync.
Connecting payments and compliance to your retail operations without manual data entry.
Want a Shopify integration you can actually operate?
We’ll review your store workflow (orders, stock, fulfillment), your ERPNext configuration, and the failure modes you’ve already seen - then propose a rollout that is observable, replay-safe, and audit-ready.