Connecting two systems is a technical event. Making them behave as one reliable operation is systems engineering.
A supplier may say, “Integration is easy. We have an API.” That is encouraging, but it answers only a small part of the question. An API can expose a command to create a transport mission. It does not automatically establish when a mission should exist, which system owns its status, how duplicate requests are avoided, or what happens if a pallet is missing after the robot arrives.
The hard part of WMS-to-AMR integration is not moving a message across the network. It is agreeing on the meaning of that message in the real warehouse.
Define the system boundaries first
Identify every participant: ERP, WMS, MES where applicable, fleet manager, robot controller, conveyors, doors, lifts, scanning stations and the operator interface. Not every project uses every system. For each function, assign one source of truth.
Who decides that a pallet is ready? Who owns location inventory? Who schedules the transport? Who controls traffic? Who confirms that the load was physically transferred? Who may cancel a mission? The answers should be explicit in an interface responsibility matrix.
Without clear boundaries, two systems may both believe they own a mission, or neither system may respond when it fails. Integration problems often appear to operators as “the robot is waiting,” even when the actual failure is an undefined business rule.
Describe the transport as a state machine
Before selecting API endpoints, define mission states and their allowed transitions. An illustrative sequence might be:
Requested → Validated → Assigned → En route to pickup → At pickup → Load confirmed → En route to destination → Delivered → Completed.
Add explicit states or reason codes for rejected, blocked, cancelled, timed out and manual intervention required. Decide which event advances inventory status. A robot reaching a location does not necessarily prove that a pallet was correctly loaded or unloaded.
Every state should have an owner, timestamp, unique mission identifier and clear meaning. If a system reports “complete,” everybody must know whether this means the robot arrived, the load sensor confirmed transfer, the operator accepted the pallet, or WMS inventory was updated. These are not interchangeable events.
Make retries and duplicate messages safe
Industrial networks experience interruptions. A client may send a request, fail to receive the response and retry. If both requests create separate transport missions, one temporary communication problem becomes a physical workflow problem.
Use stable external task IDs and idempotent creation semantics where the interface supports them: the same business request should not create two independent physical missions. Define acknowledgements, retry policy, timeouts and reconciliation after connectivity returns. Distinguish technical receipt of a message from business acceptance of the task.
Consider ordering as well. A delayed “mission started” event must not overwrite a more recent “mission completed” state. Use sequence rules, event timestamps and authoritative status queries where necessary. Build exception handling into the interface design—not as a support workaround after go-live.
Integrate the physical handover
A software command is not the same as a successful pallet transfer. The handover may depend on a barcode, pallet-presence sensor, transfer fixture, precise location, operator confirmation or equipment interlock. Define the evidence needed for each business transition.
Example: WMS requests retrieval of pallet P-123 from location A. The AMR reaches A, but the pallet is misaligned. The mission should not quietly become “complete,” and the system should not assume the inventory record is correct. The event needs a reason code, recovery procedure and an owner who can correct either the load or the record.
Design for realistic exceptions: empty pickup, occupied destination, unexpected load, duplicate assignment, changed priority, unavailable aisle, emergency stop and operator override. The more predictable the exception logic, the less manual interpretation is required during a busy shift.
Design priority and traffic behavior together
WMS may have business priorities; the fleet manager has movement constraints. A critical replenishment request cannot be allowed to override safety requirements or create impossible simultaneous delivery promises. Agree on a dispatch policy that considers deadlines, resource conflicts, load availability, battery state and congestion.
A mission can be urgent without being immediately executable. Define how the system communicates why a request is queued and how long the status remains meaningful. This transparency is often more useful to operators than a dashboard showing only robot positions.
Secure the interface and its operational data
Use documented authentication and authorization, encrypted communication where appropriate, restricted network paths, credential rotation, controlled remote access and audit logs. Do not send personal or sensitive operational data to external services without an agreed purpose and governance model. Protect the control plane as carefully as the software interfaces.
Version the interface contract. A robot software update that changes an event name or status value can break the process even if every API endpoint remains reachable. Agree how interface changes are tested and approved.
Test the failure paths, not just the happy path
An integration FAT or SAT should verify more than “create one mission and complete it.” Test invalid destinations, duplicate requests, delayed acknowledgements, network interruptions, occupied transfer locations, cancellation, priority change, fleet-manager restart and recovery after a power loss where safe and practical.
Record expected status on both sides of each test. When an exception occurs, the WMS, fleet manager and operator should present compatible information and a defined next action.
Integration acceptance checklist
- End-to-end process map and ownership matrix approved
- Mission states, identifiers and reason codes documented
- Pickup/drop-off confirmation semantics agreed
- Retries, duplicates, timeouts and event ordering addressed
- Priority, cancellation and exception workflows defined
- Cybersecurity and interface versioning requirements assigned
- Fault-injection and restart recovery scenarios tested
- Operator escalation and support procedures documented
The engineering conclusion
A working API proves communication. A successful integration proves shared operational meaning, correct physical handover, safe recovery and trustworthy information across systems. The question is not only “Can our WMS talk to the robot?” It is “Can the entire process continue to behave predictably when something goes wrong?”
ČAMINSKI — Engineering Advisory & Project Delivery. For integration architecture and acceptance planning: office@dimitarcaminski.com.