How Wizard Labz connected a retailer's ERPNext to several online stores through RabbitMQ — so price and stock changes reach every store in seconds, and every order flows back into the ERP.
ERPNext connected to several online stores through one RabbitMQ message bus, with other systems subscribing to the same events
Orders from every store arrive as messages and become customers, addresses, sales orders and payments in the ERP
Price, stock, pricing-rule and product changes are pushed to every store when they are saved — no nightly sync, no polling
Durable queues and persistent messages: an outage delays work instead of losing it
Every incoming order payload is logged, linked to the order it created, and can be re-processed
Connection drops and processing errors alert the team's chat as they happen
The client is a retailer that sells through several online stores, alongside physical points of sale. ERPNext is the system of record behind all of them: stock, prices, customers, orders and accounting live there.
That makes the ERP the one system everything else has to talk to. Every store needs to hand its orders to the ERP, and every store needs to hear, quickly, about what changes inside it: a new price, a promotion, the last unit sold.
The business needed its sales channels and its ERP to keep working independently of each other, and to be able to prove where every order went.
Wizard Labz put a message bus between the ERP and the systems around it. Systems no longer call each other; they publish messages and consume messages, and RabbitMQ holds whatever has not been processed yet.
A RabbitMQ exchange with durable queues sits between ERPNext and the stores, one queue per store. Messages are published as persistent, so they survive a broker restart and wait for their consumer.
The ERP-side consumer reads a mapping kept in ERPNext itself: message type on one side, the handler that processes it on the other. Connection settings and mappings are edited from an ERPNext screen.
ERPNext's own webhooks are pointed at a small publishing endpoint that puts each event on the exchange with its routing key. Each store keeps only what applies to it: its own price list, sales channel and country.
A long-running worker processes one message at a time, acknowledges each one, and reconnects on its own when the connection or channel drops — announcing both the drop and the recovery to the team.
A change is published when it is saved and applied when it arrives. Nothing waits for a schedule.
Item prices, wholesale prices and dated pricing rules for a product, category or brand. Rules carry their start and end dates, so a promotion begins and ends on time.
Quantity on hand per warehouse and country. Each store applies only the stock for its own sales channel.
New and edited products, images, attributes, category and tag changes, and discontinued products removed from sale.
When an order ships, the carrier and tracking number are added to the customer's order in the store.
Each store publishes its orders. The ERP matches or creates the customer and addresses, builds the sales order with the right taxes and shipping, and records the payment.
Later information, such as a fraud-screening decision, arrives as its own message and updates the order that already exists.
How fast is it? There is no polling interval anywhere in the path, so the delay is a few short hops: the ERP's background job, the broker, and the store writing the change. Our engineering estimate is a few seconds end to end, against minutes or hours for a scheduled sync. The white paper breaks that estimate down hop by hop.
Other subscribers. The same events are available to any system that binds a queue. The client's point-of-sale system is a separate project of ours and consumes price, stock and product events the same way.
An order's path from a store into the ERP. The same pieces carry ERP events back out in the other direction.
A store only needs the broker to be reachable to take an order. The ERP can be restarted, upgraded or busy; messages wait in the queue and are processed when it is back.
Every order payload is stored and linked to the sales order it produced. When processing fails, the error is recorded, the team is alerted, and the stored payload can be run again.
Before creating anything, the handler checks for an existing customer and existing addresses, so repeat buyers and re-processed messages do not multiply records.
A new store gets its own queue and three settings. A new kind of message gets a handler and a mapping row. Neither needs another point-to-point integration.
The white paper covers the architecture, every real-time update and what each store does with it, the order flow step by step, a hop-by-hop latency estimate, the open-source version, and an estimate of what it takes to adopt.
Download the White Paper (PDF)Direct download, no email required — or have it sent to you:
The bus described here proved the pattern in production. We are now building it as a general, open-source ERPNext app, so that any ERPNext site can publish and consume messages the same way. It is in active development.
Running ERPNext with online stores around it? Tell us about your setup.
Wizard Labz LLC
Wizard Labz connects the systems a business already runs on — ERPs, online stores, points of sale and internal tools — so information moves between them reliably and people stop filling the gaps by hand.
Related work on messaging and eCommerce.
Tell us what is going on. We'll reply by email and say honestly whether we can help.
