Here's the verdict up front: in an AMR–WMS integration, writing the API is about 20% of the work. The other 80% is deciding who generates the transport tasks and which layer receives the vehicle status.
I've led 30+ WMS go-lives, nine of them with AMRs. Here's a selection rule you can copy: under 10 robots from a single vendor, let the WMS drive them directly. Ten to fifty robots, single vendor, put the vendor's RCS (robot control system) in the middle. Over fifty robots, or a mixed-vendor fleet, build a task-pool layer. Rules of thumb from the field, not a standard.
Why does it come down to "who creates the task, who gets the status"? The WMS speaks business — which order, which location, what goods. The RCS speaks vehicles — which robot is free, which aisle is blocked, which battery is dying. Integration is translation between the two. Mistranslate, and freight goes to the wrong place.
The Three AMR–WMS Integration Patterns, Side by Side
| WMS drives directly | RCS in the middle | Task-pool pattern | |
|---|---|---|---|
| Who creates tasks | WMS sends tasks straight to each robot | WMS sends business tasks; RCS breaks them into vehicle moves | An independent orchestration service dispatches everything |
| Who handles fleet logic | WMS, with simple rules | RCS owns it (routing, obstacle avoidance, charging) | Task pool + each vendor's RCS |
| Status feedback | Robot → WMS, coarse-grained | RCS → WMS against an agreed status set | Task pool aggregates, then reports to WMS |
| Fits fleet size | Under 10 robots | 10–50 robots, single vendor | 50+ robots, or mixed vendors |
| Integration effort | Small | Medium | Large |
| Biggest trap | WMS doesn't understand vehicles — gridlock | Status mapping mismatches | The task pool becomes a new single point of failure |
| Typical timeline (field experience) | 2–4 weeks | 6–10 weeks | 3–6 months |
Pattern 1: WMS Drives Directly — Fewest Interfaces, Breaks as the Fleet Grows
How it works: the WMS assigns a transport task (A to B) directly to each robot, which reports "done" back.
Where it fits: pilots under 10 robots on fixed routes — say, full-pallet moves from receiving to storage on two lanes.
Where it breaks: the WMS doesn't know where the robots are, their battery levels, or whether the aisle ahead is blocked. In 2023, a 3C accessories warehouse in Suzhou — 12,000 square meters, 18 lift-type AMRs wired straight into their legacy WMS. In week two of go-live, the WMS dumped 40+ tasks at once; six robots wedged at an aisle entrance, and staff took half an hour to untangle them by hand. The sneakier bug: WMS tasks carried no task-type field, so robots couldn't tell putaway from replenishment — a replenishment pallet went to the outbound dock.
The fix: we inserted a thin task-queue service between them — the WMS throws tasks in, the service assigns by robot availability, battery, and position. Cost: go-live slipped six weeks.
I've seen this exact failure three times. Direct drive isn't wrong — it's just only safe when the fleet is small, the routes are simple, and the task mix is uniform.
Pattern 2: RCS in the Middle — The Current Mainstream for AMR–WMS Integration
How it works: the WMS only issues business tasks ("move pallet P123 from location A-01-02 to dock D3"). The RCS decomposes them into vehicle moves, assigns robots, plans paths, and manages charging. Status flows back from the RCS to the WMS on an agreed contract.
This is the most stable choice today for 10–50 robots from one vendor: the WMS never has to understand vehicles; the RCS never has to understand business.
But there's a trap nearly everyone walks into: status mapping. In 2024, a cross-border e-commerce warehouse in Nansha, Guangzhou — 32 fork-type AMRs from two vendors, two RCS instances, one WMS on top. Vendor A's RCS reported only three task states (running, done, error); vendor B had nine. Vendor A's "paused" got translated as "done" — the pallet was still halfway across the building while the WMS had already booked it as received. Sixty-plus pallets of discrepancy, a full day of cycle counting to reconcile.
The fix: a unified status-mapping table. Whatever states a vendor's RCS produces must collapse into eight standard states before reaching the WMS — queued, running, paused, error, done, cancelled, timed out, manual takeover. The WMS team owns the table, the RCS vendors comply, and it goes into the contract as an appendix. I've seen this failure three times; on the third one I finally wrote it into the contract before signing.
Pattern 3: Task Pool — Heavy Lifting for Large, Mixed-Vendor Fleets
How it works: an independent task-orchestration service (the task pool) sits between the WMS and each vendor's RCS. The WMS drops business tasks in; the pool assigns them across vendors for globally optimal dispatch; status is aggregated by the pool before flowing back to the WMS.
Where it fits: 50+ robots, or warehouses committed to a mixed-vendor fleet. The payoff: swapping AMR vendors later means changing the pool's driver, not touching the WMS.
The price: the task pool is itself a new system someone must maintain — and a single point of failure. If it goes down, the whole floor stops, so it needs high availability. Integration plus testing runs three to six months in my experience.
The Counterintuitive Truth: Development Is Never the Expensive Part
Here's the counterintuitive call: in AMR integration projects, API development is typically a fifth of total effort. What burns the budget is discovering during integration testing that the business logic doesn't line up. Example: the WMS defines "task done" as "goods arrived," the RCS as "robot arrived." The robot shows up, reports done, and the goods are still on its back. The books go wrong.
These problems die with one extra question during requirements. Discovered at integration-test time, they turn into a three-way argument between the WMS team, the RCS vendor, and the site crew that drags on for weeks. My practice: before the contract is signed, the definition of "done" goes into an appendix, and both sides sign it. An awkward conversation up front beats a shouting match on go-live eve.
One more thing people forget: who issues charging tasks? The RCS, never the WMS — the WMS doesn't know which chargers are occupied. On one project the WMS dispatched low-battery robots to charge on a schedule — eight robots queued for four chargers while their tasks timed out. Let the RCS own charging; the WMS only needs a timeout notification.
Go-Live Eve Checklist: Check Every Box
Task dispatch:
- Every task carries a globally unique ID; redispatching the same ID must be idempotent (executed exactly once).
- Every task carries a task type (putaway / replenishment / outbound / transfer). The RCS is not allowed to guess.
- Task timeout values are agreed on both sides; on timeout the WMS can cancel and the RCS must honor it.
- When a task is cancelled while the robot carries goods, there must be an explicit rule for the goods.
Status feedback: 5. The eight-state mapping table is signed by both sides and attached to the contract. 6. The RCS heartbeats to the WMS (about once per second, or equivalent); if the heartbeat stops for more than ~30 seconds, the WMS must alarm. 7. Failed status reports are cached locally and retried — no dropped status. 8. "Manual takeover" must be reported — the WMS needs to know a human is driving that robot.
Exceptions and the floor: 9. Charging tasks are issued by the RCS; the WMS never commands charging directly. 10. E-stop, load detachment, and dropped-goods events must reach the WMS (or the on-duty phone) within the agreed window. 11. After manual intervention, whether the task resumes or is voided is decided by a pre-written rule. 12. The robot's default behavior on network loss (wait in place vs. return to charger) is decided in advance.
Data alignment: 13. Location codes are identical in WMS and RCS — case, hyphens, every character. 14. Pallet barcode rules match; any code the RCS scans must be recognized by the WMS. 15. Docks, chargers, and staging areas are named one-to-one across both systems.
Load testing: 16. Run at 1.5× peak-season task volume for four continuous hours; watch congestion and timeout rates. 17. Simulate three failures — RCS down, WMS down, single robot fault — and walk the recovery procedure for each. 18. Reconcile books to floor: during the test, randomly pick 50 pallets; the WMS book location and the physical location must match.
A checklist isn't decoration — on go-live eve, tick each item and have the owner sign. Add your site's special cases on top.
By Lin Xiao, WMS Implementation Consultant
