The integration between AMR fleet software and a warehouse management system is, in theory, straightforward: the WMS has tasks, the AMR system has robots, you connect them. In practice, this integration is one of the most common sources of deployment delays and post-launch reliability issues we encounter. Not because the technical problem is hard, but because the choices made early in the integration design — which protocol, which data model, where fault tolerance lives — compound significantly as deployment scale and operational complexity grow.
We've seen four integration patterns in the field. Each has a legitimate use case. Here's an honest accounting of what each one costs and what it buys you.
Pattern 1: REST Push (WMS Calls AMR Fleet API)
The WMS calls a REST endpoint on the AMR fleet manager to dispatch tasks. The fleet manager accepts the request synchronously and returns a task ID. Subsequent status updates flow back to the WMS via webhook callbacks or a polling endpoint.
What it buys you: Simplicity. REST is understood by every WMS integration developer. Authentication is standard (OAuth2 or API key). Error semantics are clear: HTTP 4xx means the request was rejected, HTTP 5xx means the fleet manager had a problem. Implementation effort for a basic integration is typically 2–4 days for an engineer who knows the WMS API.
What it costs you: The WMS becomes the synchronous caller, which means WMS slowness or downtime directly affects task dispatch latency. If the WMS experiences a database lock during a wave release and takes 8 seconds to dispatch a task, the AMR sits idle for those 8 seconds. More critically, the webhook callback model for status updates requires the WMS to expose an inbound HTTP endpoint, which creates a firewall rule requirement that some IT organizations resist. We've seen integration projects stall for weeks on the firewall approval for an inbound webhook endpoint.
A typical task dispatch payload for this pattern:
POST /api/v1/tasks
{
"task_id": "wms-20250905-00481",
"type": "pick",
"source_location": "A-14-3",
"destination_location": "PACK-STATION-7",
"priority": 2,
"wave_id": "WAVE-0905-AM2",
"deadline_utc": "2025-09-05T09:45:00Z"
}
The deadline_utc field is important — without it, the fleet manager has no timing context for how to prioritize this task against others in the queue, and timing-window-aware dispatch (covered in our earlier pick-slot article) can't function correctly.
Pattern 2: MQTT Event Stream (Bidirectional Pub/Sub)
Both the WMS and the AMR fleet manager connect to a shared MQTT broker. Task dispatch events flow on a wms/tasks/dispatch topic; status updates flow on amr/tasks/status and amr/robots/position. Neither system directly calls the other — they exchange messages through the broker.
What it buys you: Decoupling. Neither system needs to know the other's endpoint or be reachable when the other sends a message. The broker buffers messages, so a temporary fleet manager restart doesn't cause WMS task dispatch to fail. For facilities with high task dispatch rates (300+ tasks per hour), the throughput capacity of a well-configured MQTT broker significantly exceeds what REST HTTP round-trips can sustain. Robot position telemetry flowing on amr/robots/position at 2 Hz gives the WMS real-time fleet visibility at low overhead — something the REST pattern can only approximate with expensive polling.
What it costs you: Operational complexity. You now have an MQTT broker to run, monitor, and keep available. Message delivery semantics require explicit choice: QoS 0 (fire and forget — fast, lossy), QoS 1 (at least once — potential duplicates), QoS 2 (exactly once — expensive). Task dispatch should use QoS 2 or at minimum QoS 1 with idempotent task IDs; telemetry position data is fine at QoS 0 since stale position data is preferable to position backlog. Getting QoS wrong per-topic is a class of bug that's annoying to diagnose in production.
We recommend this pattern when the WMS team has broker infrastructure experience or the facility already runs MQTT for other IoT systems (dock door sensors, conveyor monitoring, etc.). Bolt-on MQTT where neither team has operated a broker before tends to create support liability.
Pattern 3: File Polling (Shared Directory or SFTP Drop)
The WMS writes task files (typically CSV or JSON) to a shared network directory or SFTP location at wave release intervals. The AMR fleet manager polls the directory, ingests new files, processes tasks, and writes status update files back.
What it buys you: Compatibility with legacy WMS systems that don't have REST APIs or messaging broker support. Some WMS deployments — particularly older on-premises installations — have this as their only supported integration mechanism. File polling also gives operations teams a human-readable audit trail: you can open the task file and read what was dispatched.
What it costs you: Latency and fragility. A typical polling interval of 30–60 seconds means task dispatch latency can be nearly a full minute from wave release. At high task volumes this creates burst processing at each poll interval, which can cause fleet manager queue spikes. File locking on shared network directories is a common source of intermittent failures that are difficult to reproduce and maddening to debug. We've seen race conditions where the WMS was still writing a task file when the fleet manager started reading it, producing partial task ingestion with no error signal.
If this is your only option due to WMS constraints, enforce an atomic write pattern: the WMS writes to a temp file and renames it to the target filename when the write is complete. The fleet manager only processes files whose names match the final naming pattern, not temp names. That one convention eliminates most of the race condition class.
Pattern 4: Middleware Adapter (VDA 5050 or Custom Translation Layer)
A middleware component sits between the WMS and the AMR fleet manager. It handles protocol translation, data model mapping, and sometimes retry logic. In the automotive and logistics industry, VDA 5050 (the standardized AMR interface specification published by the VDA) is increasingly used as the protocol for this middleware layer, though adoption is still uneven across WMS vendors.
What it buys you: Clean separation of WMS-specific integration logic from AMR fleet manager internals. If you ever switch WMS providers or add a second AMR vendor, the middleware absorbs the change. VDA 5050 compatibility in particular allows integration with WMS products that have built-in VDA 5050 connectors — reducing custom integration work to near zero for those systems.
What it costs you: Another system to build, maintain, and monitor. The middleware becomes a critical path component: if it's down, the WMS can't dispatch to the AMR fleet. Operationally, it adds a layer to debug when things go wrong ("is this a WMS problem, a middleware problem, or an AMR problem?"). For smaller deployments where the WMS and AMR systems will never change, this overhead rarely pays for itself.
We've implemented our VDA 5050 adapter as a thin stateless translation service: it maps VDA 5050 order messages to our internal task schema and translates our order_state responses back to VDA 5050 orderState messages. No queue, no state — just schema mapping and HTTP proxying. That keeps the middleware footprint small enough that it's not an availability liability.
How to Choose
The decision is mostly driven by WMS capability and facility operational tier:
- Modern WMS with REST API support, low-to-medium task volume (<150 tasks/hour per robot): REST push. Simple, fast to implement, works well.
- Modern WMS, high task volume or real-time position visibility required: MQTT event stream. Worth the broker overhead.
- Legacy WMS with no API: file polling with atomic write convention. Not ideal but functional.
- Multi-WMS environment, multiple AMR vendors, or VDA 5050 WMS support: middleware adapter.
We're not saying any of these patterns is universally better — the right choice depends on the WMS environment, IT constraints, and operational volume. What we've found is that the most common mistake is choosing the pattern that sounds most modern (MQTT, VDA 5050) without accounting for the operational burden of maintaining the infrastructure it requires. The REST push pattern gets underestimated because it seems simple. Simple integrations that work reliably are valuable, and simple integrations that work reliably are harder to build than they look — but not as hard as debugging a misconfigured MQTT QoS level at 2am during peak shift.
