Syncing Priority ERP With Shopify: The Four Flows and Where They Break

"Connect Priority to the store" sounds like one project, which is why it gets priced wrong and breaks halfway. In practice it is four separate one-way flows, each with a different source of truth, a different freshness requirement and a different failure mode. Separating them is the one architectural decision that actually matters.

This guide assumes basic familiarity with the Priority API. For the technical error detail see the errors that waste the most time.

The four flows

Note that only one of the four is urgent. That is a significant relief: you do not need a real-time architecture for the whole system, only for one path.

Source of truth - per field, not per system

This is the mistake that repeats on every first project: you decide "Priority is the source of truth" and then the sync overwrites the product descriptions and images the marketing team spent two weeks on.

The split that works:

• ERP owns: SKU, price, stock, active status, VAT group, unit of measure
• The store owns: marketing name, description, images, categories, SEO text, URL handle

The practical consequence: the sync updates fields, not products. Updating a product in the store should push only the fields the ERP owns - not a full object that flattens everything else. It sounds obvious and it is exactly what breaks in practice.

The key that joins them

You need a stable identifier linking a Priority item to a store item. SKU is the natural choice, but only if it is genuinely unique and genuinely stable. In many businesses SKUs have changed historically, or variants share one. Check this before writing code - a single query counting duplicate SKUs saves a week.

Stock - harder than it looks

Stock sync is one-way and apparently trivial, but three questions decide whether it works:

1. Which stock? Physical, available-to-sell, or physical minus open orders? Online selling almost always wants available - otherwise you sell items already allocated to another order.
2. Which warehouses? With several, you must decide which ones the store sells from. Blindly summing everything commits you to stock sitting in another branch.
3. What happens at zero? Mark out of stock, hide the product, or allow backorder? That is a business decision, not a technical one, and it is worth getting in writing.

On frequency: every 15-60 minutes suffices for most businesses. Anyone selling single-quantity items in high demand needs more, but at that point the real question is whether the system should be selling that stock without allocation at all.

Orders - the only flow that must be fast

An order placed in the store needs to reach Priority quickly, because the entire operational process depends on it. The pattern that works:

1. The store sends a webhook on a new order.
2. Your endpoint validates the signature, writes the raw order to a queue or table, and responds immediately.
3. A separate worker processes the queue: matches the customer, maps items, and creates the document in Priority.
4. The created document ID is stored alongside the store order ID.

The reason for the split: creating a document in Priority involves customer matching, validations and sometimes several calls. If all of that happens inside the webhook, any slowdown on the ERP side becomes a failure on the store side.

Atomic creation: the Priority API lets you create a document with its lines in a single request by nesting the subform array in the body. Use it. Creating a header and then lines in separate calls leaves a partial document behind if something fails midway.

The part that is all the work: customers

This is the expensive part, and the part that stays invisible until it detonates. A store customer is identified by email; a Priority customer is a customer card with a number. Matching between them is business logic, not technical logic.

The safe rule: never let the integration create a new customer card blindly. When no confident match is found, it is better to book the order under a walk-in customer and flag it for review than to create a duplicate. Duplicate customer cards do not surface in testing; they surface six months later, in a report that does not add up.

Fulfilment - the flow most often forgotten

When a shipping document is created in Priority, the store order should move to "shipped" and receive a tracking number. This is the flow most often deferred to phase two, and also the one that generates the most support contacts when it is missing.

Here Priority webhooks fit precisely: there is a clear document status transition, which is exactly what the mechanism is built for. On an installation without the Webhooks module licence, scheduled polling of the last day's shipping documents does the job.

What every integration of this kind must have

• A documented two-way link. The store order ID on the Priority document, and the document number on the store order. Without it, every enquiry becomes a manual comparison.
• Idempotency. The same order arriving twice must produce one document. Webhooks get redelivered; this is not an edge case.
• A daily reconciliation job. Compare store orders against Priority documents for the last 24 hours and alert on gaps. That is what catches whatever the silent failures missed.
• An error queue a human sees. An order that failed to import must appear somewhere someone looks every morning. An order stuck in a log is a lost order.

The same principles apply to WooCommerce and any other store platform - what changes is the store's API, not the shape of the integration.