Every online order that gets retyped into the ERP is a mistake waiting to happen. Here is how store-to-ERP integration actually works - which direction each piece of data flows, what breaks first, and what it costs to build properly.
Key takeaways
- Store-to-ERP is not one integration. It is four separate flows - orders, inventory, products, customers - and each has its own direction, frequency and failure mode.
- Decide which system is the master for each data type before you write a line of code. Two systems that both think they own inventory will fight, and the customer sees the loser.
- Make every write idempotent and keyed on the store order number. Networks fail mid-request, and the recovery path must never create a duplicate invoice.
- Budget for the error queue and the alerting, not just the happy path. The integration is only useful if someone finds out the same day that 12 orders did not sync.
Connecting an online store to an ERP means automating four flows: new orders from Shopify or WooCommerce into the ERP, stock and prices back to the store, and shipping status once the order is fulfilled. In a Priority ERP Shopify integration, a Shopify webhook feeds a small queue service that writes each order to Priority's REST (OData) API, and a scheduled job pushes stock back.
The pattern is always the same. The store runs on Shopify or WooCommerce. The business runs on Priority, SAP Business One or Hashavshevet. Between them sits a person with two browser tabs, copying order details from one into the other. At 20 orders a day it is annoying. At 200 it is a full-time job that produces typos in customer addresses and invoices with the wrong VAT.
This guide covers what a proper store-to-ERP integration looks like, the decisions that determine whether it works, and what it costs.
Who can integrate Priority ERP with Shopify?
I build this integration myself. As a development business in Israel, I build store-to-ERP connections for Priority, SAP Business One and Hashavshevet as custom code rather than an off-the-shelf connector. Orders plus stock with an error queue sits in my multi-step automation row: $1,800 - $8,000, typically 2 - 5 weeks.
Before quoting I ask for three things: a Priority sandbox, an API user whose forms are enabled for API access, and the list of custom fields on your order form. The full price list is on the pricing page.
It Is Four Integrations, Not One
The single biggest scoping mistake is treating "connect the store to the ERP" as one project. It is four flows, and you do not need all of them on day one.
| Flow | Direction | Typical trigger | Priority |
|---|---|---|---|
| Orders | Store → ERP | Webhook on order paid | Build first |
| Inventory levels | ERP → Store | Scheduled, every 15-60 min | Build second |
| Products and prices | ERP → Store | Scheduled, nightly | Only if the catalogue changes often |
| Customers | Both, with rules | On order creation | Usually rides along with orders |
Shipping status and returns are a fifth flow that most businesses can keep manual far longer than they expect.
Decide the Master System First
For each data type, exactly one system is the source of truth and the other is a mirror. Getting this wrong is the cause of most of the pain people blame on "the integration being buggy".
- Inventory: the ERP wins. It knows about warehouse stock, reserved units, goods in transit and returns. The store gets a number pushed to it and never decides stock on its own beyond the checkout reservation.
- Orders: the store wins. The order was placed there, the customer got that confirmation email. The ERP receives it and must not silently modify the line items.
- Prices: usually the ERP, unless marketing runs promotions in the store. If both need to set prices, split it explicitly - base price from the ERP, discounts owned by the store - and never let both write the same field.
- Customers: messy. The store creates guest checkouts; the ERP has an accounting-grade customer master. The workable rule is to match on a normalised email or tax ID, create in the ERP when no match exists, and never overwrite ERP customer records from store data.
The Israeli Stack in Practice
Priority has a well-documented REST API and is the smoothest of the local ERPs to integrate. Orders, customers, items and stock are all reachable. The usual friction is form and field naming - Priority installations are heavily customised, so the field you need is often a customer-specific extension rather than a standard one.
SAP Business One exposes the Service Layer (OData). Capable and well structured, but heavier: sessions, stricter object models, and less forgiving error handling. Expect more time on the ERP side than on the store side.
Hashavshevet is the oldest of the three and the most variable. Depending on version and installation you may be working against a local API, an ODBC connection, or a file-based import. Confirm which one you actually have before scoping - this single fact can double or halve the estimate.
Rivhit and cloud invoicing services generally offer a straightforward HTTP API and are the easiest case, though they cover invoicing rather than full ERP functionality.
Priority ERP Shopify Integration: The Calls on Each Side
A Priority ERP Shopify integration is two documented APIs and one service between them. These are the calls that service makes, taken from Shopify's developer documentation and Priority's REST API documentation:
| Job | Shopify side | Priority side |
|---|---|---|
| Authentication | An Admin API access token from the app installed on the store. Webhooks are signed: X-Shopify-Hmac-SHA256 is an HMAC-SHA256 of the raw body, keyed with the app's client secret | Basic auth with a Personal Access Token as the username and the literal word PAT as the password. The upper-level forms must be enabled for API access |
| New order | Webhook topic orders/paid (or orders/create) | POST /ORDERS with CUSTNAME and the lines nested in ORDERITEMS_SUBFORM (PARTNAME, TQUANT, DUEDATE) in one request |
| Stock to the store | inventorySetQuantities mutation | A scheduled read; $since returns only records changed after a given time. Which form holds sellable stock depends on the installation |
| Fulfilment back | fulfillmentCreate mutation, with tracking | A BPM rule on the shipping document fires a webhook (Webhooks module), or a scheduled poll |
| Limits | GraphQL is metered in cost points; a single query may cost at most 1,000, and a throttled call returns THROTTLED | Priority Cloud allows 100 calls a minute per tenant and answers 429 above it; one GET returns at most MAXAPILINES rows (2,000 by default from version 25.1) |
- Shopify waits 5 seconds. A webhook endpoint has one second to accept the connection and five seconds to answer. On an error Shopify retries 8 times over 4 hours, and a subscription created through the Admin API is deleted after 8 consecutive failures. That is why the endpoint only stores the order and returns 200.
- Build on GraphQL. Shopify marked the REST Admin API as legacy, and since April 1, 2025 new public apps must use the GraphQL Admin API only.
- Priority's
$batchis not a transaction. It takes up to 100 operations, and the documentation states there is no rollback: whatever was saved stays saved. The nested POST is the safer way to write an order with its lines. - Keep Priority's error text verbatim. A rejected write returns the form's own validation message under
InterfaceErrors, the same text a user would see on screen. The common ones are in Priority REST API errors.
Stock - harder than it looks
Stock sync is one-way and apparently trivial, but three questions decide whether it works:
- 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.
- Which warehouses? With several, you must decide which ones the store sells from. Blindly summing everything commits you to stock sitting in another branch.
- 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:
- The store sends a webhook on a new order.
- Your endpoint validates the signature, writes the raw order to a queue or table, and responds immediately.
- A separate worker processes the queue: matches the customer, maps items, and creates the document in Priority.
- 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.
What changes when the store is WooCommerce?
A WooCommerce to Priority integration has the same four flows and the same Priority side; only the store API changes. WooCommerce exposes its REST API under /wp-json/wc/v3/ with a consumer key and secret, and signs each webhook with X-WC-Webhook-Signature, a base64 HMAC-SHA256 of the payload keyed with the webhook's secret.
One difference matters in production: WooCommerce disables a webhook after five consecutive failed deliveries, and it stays off until someone re-enables it. A Priority outage that lasts an afternoon can switch off the order flow without any error on the store side, which is one more reason the daily reconciliation job is not optional.
The Parts People Skip
Idempotency
A webhook fires, your service starts creating the ERP order, the connection drops before the response comes back. Shopify retries. Without protection you now have two orders and two invoices. The fix is to key every write on the store order number, check for an existing record before creating, and store the resulting ERP document ID so a retry becomes a no-op.
The error queue
Orders will fail to sync - an item missing from the ERP catalogue, a customer with an invalid tax ID, a temporary outage. They must land in a visible queue with the error text and a retry button, not disappear into a log file. This is the single feature that separates an integration people trust from one they check manually anyway.
Alerting
A daily summary is not enough. If nothing has synced in two hours during business hours, someone should get a message. Silent failure is the expensive one.
Partial failures
An order syncs but its customer record does not. Decide up front whether that is a hard failure that rolls back, or a soft one that flags for review. Both are defensible; being undecided is not.
What It Costs
| Scope | Typical build |
|---|---|
| Orders only, standard ERP fields, no customisation | 1-2 weeks |
| Orders + inventory, error queue, alerting | 2 - 3 weeks |
| All four flows, heavily customised ERP, multi-warehouse | 5 - 8 weeks |
Off-the-shelf connectors exist and are worth evaluating first. They tend to work well when your ERP is close to stock configuration and break down when it is not - which, for Priority and SAP B1 in Israel, is most of the time.
Start With Orders Only
Ship the order flow alone, run it in parallel with the manual process for a week, and compare. You will find the field mismatches and the edge cases with no risk. Then turn off the manual process and add inventory.
The businesses that get burned are the ones that switch on four flows at once and then cannot tell which of them is producing the wrong stock numbers.
If you want the flows mapped for your specific store and ERP, book a free call. Related reading: CRM, ERP and app integration for small business and how to automate inventory management.
Sources
Frequently asked questions
Should I use an off-the-shelf connector or build a custom integration?
Evaluate the connector first - it is always cheaper when it fits. It fits when your ERP is close to its stock configuration and you need only standard fields. It stops fitting when your Priority or SAP B1 installation has customer-specific fields, when you have multi-warehouse logic, or when your customer matching rules are unusual. In Israel that describes most established installations, which is why custom integrations are common here.
How often should inventory sync from the ERP to the store?
Every 15 to 60 minutes covers almost every business. Push more frequently only for genuinely scarce items where overselling is expensive - and for those, a targeted event-driven update on stock movement is better than shortening the interval for the whole catalogue. Full catalogue syncs every few minutes create load on the ERP for no practical benefit.
What happens to orders placed while the ERP is down?
Nothing should be lost, and the store should keep selling. The integration receives the webhook, writes the order into its own queue, and acknowledges immediately. A worker then drains the queue into the ERP with retries and backoff. Orders that still fail after the retry budget land in a visible error queue with the failure reason. This is why the integration needs its own storage rather than being a pass-through.
Can the integration create the invoice automatically?
Technically yes in every one of these systems, and it is a common requirement. The caution is that an invoice is a financial and regulatory document, so automatic issuance should be reviewed with your accountant before it goes live, and it must be strictly idempotent - a duplicate invoice is a real problem, not just a data error. Many businesses start by creating a draft document automatically and having a person approve issuance for the first few weeks.
Which flow should I build first?
Orders, store to ERP, and nothing else. It removes the most manual work, it is the easiest to validate against the existing manual process, and it does not risk showing customers wrong stock. Run it in parallel with the manual entry for a week and compare the results before switching off the manual process. Inventory comes second because a bug there is customer-visible.
Can Priority ERP be connected to Shopify?
Yes. Priority exposes a REST/OData API for reading and writing items, stock, customers and documents, and Shopify exposes its own admin API plus webhooks. The integration is built as four separate flows - catalogue and stock from the ERP to the store, orders from the store to the ERP, and fulfilment status back to the store.
What is the most expensive mistake in an ERP to store integration?
Letting the integration create ERP customer cards automatically when it cannot confidently match an existing one. Duplicate customer records do not fail any test - they accumulate silently and surface months later as reports that do not reconcile. Booking an unmatched order under a walk-in customer and flagging it for review is far cheaper to fix.
How do you stop the same order being imported twice?
Store the store's order ID on the ERP document and check for it before creating anything. Webhooks are redelivered as a matter of course, so idempotency is a requirement rather than an edge case. A daily reconciliation job comparing store orders against ERP documents catches whatever slips through.
Who can integrate Priority ERP with Shopify?
We are a development business in Israel that builds Priority ERP Shopify integrations as custom code: a Shopify webhook into a queue service that writes orders to Priority's REST API, with stock and shipping status synced back to the store. Orders plus stock with an error queue is priced at $1,800 - $8,000 and usually takes 2 - 5 weeks.
Which Shopify API should a Priority integration use?
The GraphQL Admin API. Shopify marked the REST Admin API as legacy, and since April 1, 2025 new public apps must use GraphQL only. Stock goes out with the inventorySetQuantities mutation, shipments with fulfillmentCreate, and new orders arrive by a webhook signed with the X-Shopify-Hmac-SHA256 header.
How does a WooCommerce store connect to Priority?
On the Priority side exactly as with Shopify: the order is written to the ORDERS form with its lines nested in one request. On the store side WooCommerce uses its REST API under /wp-json/wc/v3/ and signed webhooks. Watch the delivery log, because WooCommerce disables a webhook after five consecutive failed deliveries.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
Have a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.