WMS to ERP Integration: REST vs Message Queue

Part of the Scalable WMS Architecture guide. This deep-dive expands on the ERP integration section of the pillar.

A WMS almost never lives alone. It has to tell the ERP what shipped so an invoice can go out, pull purchase orders so receiving knows what to expect, and keep inventory counts agreeing across two systems that each think they own the truth. The shape of that integration, synchronous REST calls or an asynchronous message queue, is one of the more consequential decisions in a warehouse build, because it determines what happens when one of the two systems is slow, down, or wrong. This post compares the two approaches honestly, including where each fails, and lands on the hybrid we actually use.

The two systems do not keep the same hours

The core tension is that a WMS and an ERP have different rhythms. The warehouse is real-time and physical: a carton is scanned, a pick is confirmed, a truck leaves. The ERP is transactional and financial: it cares about orders, invoices, and the general ledger, and it is often slower, rate-limited, or only reachable in batch windows. Wiring a fast, high-frequency system directly into a slower, more fragile one is where integrations go to die. The pattern you choose is really a choice about how much you let one system's bad day become the other's.

REST: synchronous, simple, and tightly coupled

The straightforward approach is direct API calls. When a shipment is confirmed, the WMS calls the ERP's REST endpoint and waits for a response. It is easy to reason about, easy to build, and easy to debug, because the call and its result are right there in one request.

This is genuinely the right choice in a large share of cases, and it is the approach we reach for first. On Lorecs, our five-year supply chain engagement, the platform integrated QuickBooks across two interconnected products for unified, multi-currency accounting, taking orders and shipments through to invoicing. Much of that kind of integration is request-and-response: the system needs to create or read a specific record and get an answer. When the volume is moderate, the target system is reasonably available, and you need the result immediately, a clean REST integration with sane retries is the simplest thing that works, and simple is a feature.

REST's weaknesses appear under load and under failure. If the ERP is down, the synchronous call fails, and now the warehouse operation is blocked on the accounting system, which is exactly backwards. If the ERP is slow, your WMS request threads pile up waiting. And if you naively retry a failed call, you risk creating the same invoice twice. REST couples the two systems in time: both must be healthy at the same instant for the integration to work.

Message queue: asynchronous, durable, and decoupled

The message queue inverts the relationship. Instead of calling the ERP directly, the WMS publishes a message, "shipment 4471 dispatched," to a broker, and a separate consumer reads from the queue and applies it to the ERP at its own pace. The WMS does not wait and does not care whether the ERP is up at that exact second.

This buys the properties that matter at scale:

• Resilience to downtime. If the ERP is offline, messages wait safely in the queue and are processed when it returns. The warehouse never stops because accounting is down.
• Load smoothing. A burst of two thousand shipments at end of day does not hammer the ERP all at once. The consumer drains the queue at a rate the ERP can take.
• Decoupling. The WMS does not need to know the ERP's API shape or even that an ERP is the consumer. Add a second consumer (analytics, a data warehouse) without touching the producer.
• Retry and dead-lettering. A message that fails can be retried automatically, and one that keeps failing lands in a dead-letter queue for inspection instead of being lost.

This is the same architectural instinct behind the event-driven processing we ran on Driven, our enterprise CRM, where the platform unified more than forty third-party integrations and a change in one place emitted a message that other parts consumed rather than everything calling everything directly. At that integration count, point-to-point synchronous calls become an unmanageable web; a message-based backbone is what keeps it sane.

The cost is real, though. A queue is another piece of infrastructure to run and monitor. The flow is harder to trace, because a single business action is now spread across a producer, a broker, and a consumer. And you inherit eventual consistency: for a window after the shipment, the ERP does not yet know about it. For accounting that is usually fine. For something a user is staring at, it may not be.

Honest comparison

What "scheduled sync" really is, and its limits

There is a third pattern teams use, often without naming it: the scheduled job. A cron task wakes up every few minutes, gathers what changed, and pushes it to the ERP in a batch. It is simple, it survives the ERP being briefly unavailable (the next run catches up), and it needs no broker. We use scheduled jobs in our own systems for exactly this kind of periodic reconciliation, and for many integrations it is enough.

Its limits are latency and granularity. A batch every fifteen minutes means the ERP is up to fifteen minutes behind, and a failure in the batch can be coarse, succeeding for some records and failing for others in ways that are awkward to reconcile. Think of scheduled sync as a pragmatic middle ground: more resilient than naive REST, less immediate and less granular than a queue. It is often the right starting point, and the thing you outgrow into a queue when volume or freshness demands it.

The rule that matters more than the transport: idempotency

Whichever pattern you choose, the single most important property of a WMS-to-ERP integration is idempotency: processing the same message or making the same call twice must not create two invoices or double-count a shipment. Networks fail after the work is done but before the acknowledgement arrives, queues deliver at-least-once by design, and retries are unavoidable. The defense is to make every operation safe to repeat, typically by attaching a stable, unique key to each business event and having the receiving side reject a key it has already processed.

We learned how unforgiving this can be on Lorecs, where invoices flowing out to an external system had to be correct enough to pass an Amazon AI validation check, and the result of getting it right was zero invoice rejections. Duplicate or inconsistent records are not a tidiness problem in an ERP integration, they are a financial one. Idempotency is what makes retries, the thing both REST and queues depend on, safe.

The hybrid we actually use

Real integrations are rarely pure. The pattern we trust mixes the three by the nature of each flow:

• Synchronous REST for the handful of interactions that genuinely need an immediate answer, such as reading a purchase order at receiving time or validating a customer before committing an order.
• A message queue for high-volume, fire-and-forward events that must not be lost and must tolerate the ERP being down, such as shipment confirmations driving invoicing.
• Scheduled reconciliation as a safety net regardless of the above, a periodic job that compares the two systems and flags or fixes drift, because no real-time integration stays perfectly in sync forever.

That last point is the one teams skip and regret. Even a well-built event integration drifts, and a nightly reconciliation that catches the discrepancy before the customer does is cheap insurance.

From the author. "I start every ERP integration with the simplest thing that meets the requirement, which is usually REST or a scheduled sync, and I reach for a message queue when the volume, the need to survive the ERP's downtime, or the number of consumers makes it worth the operational cost. But the transport is the second decision. The first is idempotency. If making the same call twice can create two invoices, no amount of clever queueing will save you, and on a real warehouse that is a finance problem, not an engineering one."

Nirmal J, Team Lead, WMS and Inventory Systems at Rorix Technologies

Where this fits

ERP integration is one face of a scalable warehouse system, and it touches the others. The events you publish to the ERP are often the same events worth keeping for audit and traceability, and the database behind both systems has to keep those records consistent, which is part of the PostgreSQL versus MongoDB decision. For how integration sits alongside the real-time, data, and deployment choices in a system built to scale, see the Scalable WMS Architecture guide. The short version: use REST or a scheduled sync until volume or resilience demands a queue, add a reconciliation safety net either way, and make every operation idempotent before you make it fast.

Frequently Asked Questions

Should I integrate my WMS and ERP with REST or a message queue?

Use REST when the volume is moderate, the ERP is reasonably available, and you need the result immediately, such as reading a purchase order at receiving. Use a message queue when you have high-volume events that must not be lost, need to keep working while the ERP is down, or have many systems consuming the same data. Most mature integrations are a hybrid: REST for the few calls that need an instant answer, a queue for high-volume fire-and-forward events, and a scheduled job that reconciles drift.

What happens to inventory sync if the ERP goes down?

With a direct REST integration, the call fails and the action is blocked or must be retried, which can stall warehouse work on an accounting outage. With a message queue, the messages wait safely in the queue and are processed automatically when the ERP recovers, so the warehouse keeps operating. This resilience to the other system's downtime is the main reason high-volume integrations move from synchronous calls to a queue.

Why is idempotency so important in ERP integration?

Because networks fail and retries are unavoidable, the same shipment or invoice event can reach the ERP more than once. If your integration is not idempotent, that produces duplicate invoices or double-counted stock, which is a financial error, not just a data-quality one. The fix is to attach a stable unique key to every business event and have the receiving side ignore a key it has already processed, so repeating an operation is always safe.

Do I need a message queue for a small warehouse?

Usually not. For low to moderate volume, a clean REST integration with careful retries, or a scheduled batch sync every few minutes, is simpler to build and operate and is often entirely sufficient. A message queue adds infrastructure to run and monitor, so it earns its place when volume grows, when you must survive the ERP being unavailable, or when several systems need to consume the same events. Start simple and introduce the queue when the requirements demand it.

How do you keep a WMS and ERP from drifting out of sync?

Even a well-built real-time integration drifts over time, so the reliable safeguard is a scheduled reconciliation job that periodically compares the two systems and flags or corrects discrepancies. Combine that with idempotent operations so retries are safe, durable delivery so events are not silently lost, and clear logging so a mismatch can be traced to its cause. The reconciliation job is the cheap insurance that catches a discrepancy before a customer or an auditor does.