AMR–WMS Integration Explained: Tasks, APIs, WCS, Fleet Managers, Status Callbacks, and Failure Points

A warehouse management system (WMS) that “has an API” is not the same as a warehouse where mobile robots automatically receive tasks, execute them, and report status back to the system that manages inventory. The gap between “API exists” and “integration works in production” involves task-state machines, idempotency, timeout handling, fleet manager boundaries, and recovery logic for when things fail. This article explains the actual data flow from a business order to a robot mission, the systems involved, the interface points that determine whether integration succeeds or stalls, and what to test before go-live.

What WMS–AMR Integration Actually Connects

Integration is not a single API call. It is a chain of transformations that starts with a business order and ends with a physical robot moving a load from one location to another. Each link in this chain is a potential failure point.

The basic flow is: a WMS or ERP system creates an order (e.g., “move pallet A from storage location X to shipping dock Y”). This order must be decomposed into a robot-compatible mission: identify the source location, identify the destination, assign the mission to an available robot, transmit the mission, monitor execution, receive status updates, confirm completion, and update inventory records.

The systems involved in this chain may be provided by different vendors:

• WMS — manages inventory, orders, and stock locations. May be a commercial system (e.g., SAP EWM, Manhattan Associates, Infor) or a custom-built system.
• WCS (Warehouse Control System) — traditionally manages material handling equipment (conveyors, sorters, automated storage). In AMR deployments, the WCS role may be absorbed by the fleet manager or may exist as a separate layer that translates WMS orders into equipment commands.
• Fleet Manager (FMS) — the robot vendor’s system that manages robot navigation, traffic coordination, task allocation, and charging. This is where the robot’s path planning, obstacle avoidance, and multi-robot coordination happen.

The key point: WMS, WCS, and fleet manager are not the same system, and they are not always provided by the same vendor. Which system handles which function varies by deployment. Some AMR vendors provide a fleet manager that communicates directly with the WMS via standard APIs. Others require a WCS or middleware layer in between. Understanding which system owns which responsibility is the first step in planning integration.

WMS, WCS and Fleet Manager: Different Responsibilities

In practice, the boundaries blur. Some WMS systems include WCS functionality. Some fleet managers accept business-level orders directly. Some deployments use middleware (custom or third-party) to bridge the WMS and the fleet manager. The integration design depends on which systems are in place and what interfaces they expose.

From Business Order to Robot Mission

The transformation from a business order to a robot mission involves several steps, each of which must be defined and tested:

1. Order creation. The WMS creates an order with source and destination locations. The locations must be mapped — the WMS location code (e.g., “A-03-07”) must correspond to a robot-navigable coordinate or node in the fleet manager’s map.

2. Mission generation. The order is translated into a robot mission. This may involve the WCS, a middleware layer, or the fleet manager directly. The mission includes: source location, destination location, priority, task type (transport, pickup, drop-off), and any special instructions (e.g., wait for confirmation before dropping).

3. Task assignment. The fleet manager assigns the mission to an available robot based on proximity, battery level, current load, and traffic conditions. Dynamic reallocation may occur if a better candidate becomes available or if the assigned robot encounters a problem.

4. Mission execution. The robot navigates to the source, picks up the load (or waits for a human or automated system to load it), navigates to the destination, and drops off the load. Each of these sub-steps generates status callbacks.

5. Status reporting and completion. The robot reports status at each stage: assigned, en route to source, arrived at source, loaded, en route to destination, arrived at destination, unloaded, mission complete. The fleet manager forwards these status updates to the WMS (or WCS), which updates the order status and inventory.

API Methods, Authentication and Status Callbacks

The interface between the WMS/WCS and the fleet manager is where most integration effort is spent. Two approaches are common:

Proprietary REST APIs. The fleet manager exposes REST endpoints for task creation, status queries, and cancellation. This is the most common approach for single-vendor deployments. The advantage: direct access to vendor-specific features. The disadvantage: each vendor’s API is different, creating lock-in and making multi-vendor fleet management difficult.

VDA 5050 standardized protocol. The VDA 5050 specification, developed by VDA (German Association of the Automotive Industry), VDMA, and KIT, defines a standardized communication interface between AGVs/AMRs and a master control system. It uses MQTT (a lightweight publish-subscribe protocol) with JSON data format. The current version is VDA 5050 v3.0.0 (March 2026). VDA has archived all previous versions (including v2.1.0), which are no longer recommended for new development. Buyers should verify that their fleet management system supports v3.0.0.

VDA 5050 defines the communication structure between AGVs/AMRs and a master control system using MQTT and JSON. The current version, VDA 5050 v3.0.0 (March 2026), supersedes all previous versions. VDA has archived v2.1.0 and earlier; they are no longer recommended for new development. The specification defines eight MQTT topics for communication between the master control and each vehicle:

The zoneSet and responses topics are optional and were introduced in v3.0.0 to support zone-based traffic management and synchronous request-response communication patterns. Refer to the official VDA 5050 v3.0.0 specification for the complete JSON schema, field definitions, and connection handling details.

The factsheet topic is particularly important for procurement. Before a robot accepts orders, it publishes its factsheet — a structured declaration of its capabilities (payload, speed, dimensions, available actions, charging characteristics). The master control system uses this to determine which robots can execute which missions. If a robot’s factsheet is incomplete or inaccurate, the system may assign missions the robot cannot execute. Verify that your supplier’s factsheet implementation covers the fields required by v3.0.0.

The connection topic is the only topic that uses MQTT QoS 1 (at-least-once delivery), meaning connection status messages are guaranteed to be delivered. All other topics use QoS 0 (at-most-once delivery), meaning messages are not guaranteed — if a message is lost, it is not retried. This matters for task-state management: if a status callback is lost, the WMS may not know the robot has completed a task, leading to inventory discrepancies.

VDA 5050 also includes a Last Will and Testament (LWT) mechanism: if an AGV disconnects unexpectedly, the broker publishes a pre-defined message alerting the control system. Orders in progress are preserved and can be continued to the last released node when the AGV reconnects.

A major AMR manufacturer announced a VDA 5050 adapter in March 2025, bridging its proprietary REST interface with the MQTT-based VDA 5050 protocol. The adapter was developed in collaboration with multiple fleet management system providers, confirming that VDA 5050 is moving from specification to production deployment (manufacturer announcement, March 2025; Manufacturer-stated). Buyers should verify whether the adapter supports v3.0.0 or an earlier archived version.

Task State, Idempotency, Cancellation and Retry

Task-state management is where integration projects most commonly fail. The issues are not about API syntax — they are about what happens when things go wrong.

Idempotency. If the WMS sends the same order twice (due to a retry, a network glitch, or a user action), the fleet manager must not create two missions for the same order. Each order should have a unique identifier, and the fleet manager should recognize duplicate submissions and return the status of the existing mission rather than creating a new one. This is called idempotency, and it must be tested explicitly. For example, if the WMS retries an order due to a network timeout, the fleet manager should recognize the duplicate order ID and return the existing mission status rather than dispatching a second robot.

Cancellation. When the WMS cancels an order, the fleet manager must stop the robot — but the timing matters. If the robot has already picked up a load, cancellation requires a decision: return the load to the source, deliver it to the destination anyway, or park and wait for human instruction. The cancellation behavior must be defined in the integration specification, not discovered during production.

Timeout. If the fleet manager does not respond to a task assignment within a defined timeout period, the WMS should retry, escalate, or assign to a different robot. The timeout value must be realistic — too short, and the system generates false alarms; too long, and orders sit unassigned.

Status synchronization. If the WMS and fleet manager disagree on task state (e.g., WMS thinks the task is “in progress” but the fleet manager has marked it “complete”), inventory records will be wrong. The system needs a reconciliation mechanism — either periodic sync, event-driven updates, or a single source of truth.

Failure Points and Recovery Logic

Integration testing must cover what happens when each link in the chain fails:

Network failure between WMS and fleet manager. If the network connection drops, the fleet manager should continue executing missions already assigned. When the connection restores, it should sync all missed status updates. The WMS should detect the disconnection and mark affected orders as “status unknown” rather than assuming completion or failure.

Robot failure mid-mission. If a robot breaks down, the fleet manager should detect the failure (via heartbeat loss, error state, or manual report), reassign the mission to another robot, and notify the WMS. If the robot was carrying a load, the load must be recovered — either by another robot or by a human.

Pickup or drop-off point occupied. If the source or destination location is blocked (by another robot, a pallet, or a person), the robot should wait, retry, or alert. The fleet manager should report this as an exception, not a permanent failure. The WMS may need to reroute to an alternate location.

Inventory state mismatch. If the WMS says a pallet is at location X but the robot arrives and finds nothing (or finds a different pallet), the robot should report the discrepancy rather than completing a phantom mission. This requires the robot to have some form of load presence verification — a sensor that confirms whether something is actually on its top module or forks.

Elevator or door failure. If the robot calls an elevator and it does not respond, the mission may be blocked. The fleet manager should report the exception, and the WMS should either reroute to a path that does not require the elevator or hold the mission until the elevator is available.

Testing the Integration Before Go-Live

Integration testing should cover not just the happy path but the failure paths. A structured testing approach includes:

Unit tests. Each API method is tested individually: create order, query status, cancel order, receive callback. Verify that each method returns the expected response for valid and invalid inputs.

Integration tests. End-to-end flow from WMS order creation to robot mission completion to WMS status update. Test with a real robot (or a simulator that mimics robot behavior) to verify the full chain.

Failure scenario tests. Deliberately trigger each failure point: disconnect the network mid-mission, block a pickup point, simulate a robot error, send a duplicate order. Verify that the system handles each scenario as designed.

Load tests. Send multiple concurrent orders and verify that the fleet manager allocates them correctly without deadlocks or resource contention. Test with the expected peak order volume, not just a single order.

Reconciliation tests. After a network outage, verify that all missed status updates are synced correctly and that the WMS and fleet manager agree on task states.

An Interface Definition Checklist

Before starting integration development, define and document the following interface parameters:

Authentication and security:

• API authentication method (API key, OAuth, mutual TLS, or other)
• Network security between WMS and fleet manager (VPN, dedicated network, or other)
• Data encryption requirements for task data in transit

Task lifecycle:

• Order identifier format and uniqueness guarantee
• Task creation API method and required fields
• Status callback format and frequency
• Cancellation API method and behavior (including mid-mission cancellation)
• Timeout values for task assignment, status updates, and completion confirmation

Error handling:

• Error code definitions and meanings
• Retry policy for failed API calls (max retries, backoff strategy)
• Idempotency mechanism for duplicate order submissions
• Reconciliation procedure for status mismatches

Protocol and data format:

• Communication protocol (REST, MQTT, VDA 5050, or other)
• Data format (JSON, XML, or other)
• VDA 5050 version (if applicable; verify v3.0.0 support) and topic structure
• Factsheet fields required from the robot (payload, dimensions, available actions)

Operational:

• Location mapping between WMS location codes and robot-navigable coordinates
• Priority handling rules for concurrent orders
• Charging-aware task assignment (does the system avoid assigning tasks to robots with low battery?)
• Multi-vendor fleet management support (if applicable)
• Monitoring and alerting for integration health