Real-time manifest synchronization with WMS allocation data. The integration creates manifests in Zimark when orders reach "fully allocated" status in the WMS, extracting pallet IDs from order allocations. Subsequent allocation changes in the WMS trigger manifest updates, ensuring Zimark reflects the current state of assets ready for loading.
A third-party logistics (3PL) warehouse handles inbound shipments from multiple clients. During inbound receiving, Zimarkers are generated, coupled to each pallet, and printed on labels. This use case focuses on outbound shipments: orders leaving the 3PL warehouse to supply client locations.
Clients place orders directly into the 3PL's WMS. These orders progress through allocation, picking, and loading stages before shipment.
The integration must:
- ✅ Create manifests only when orders are fully allocated in the WMS
- ✅ Process allocation changes in real-time and update Zimark manifests
- ✅ Include customer name in manifest metadata
- ✅ Handle pallet substitutions during picking (see step 4 below)
The WMS statuses and event names below are illustrative; map them to your own WMS's actual values.
Action: Client creates order in WMS
WMS Order Status: CREATED
Trigger: WMS sends webhook/event with status CREATED
Zimark Action: None (too early - not allocated yet)
Action: Warehouse staff add/modify order details
WMS Order Status: IN_PROGRESS
Trigger: WMS sends webhook/event with status UPDATED
Zimark Action: None (wait for full allocation)
Action: WMS allocates specific pallet IDs to the order
WMS Order Status: IN_PROGRESS
Trigger: WMS sends webhook/event when status changes to FULLY_ALLOCATED
Zimark Action: ✅ CREATE MANIFEST with allocated pallet IDs
Action: Warehouse operators pick pallets. Sometimes they substitute pallets:
- Original allocation: Pallet A (damaged or inaccessible)
- Actually picked: Pallet B (same SKU, same quantity)
WMS Order Status: PICKING
Example:
- Allocated:
LPN00012345(SKU: WIDGET-A, Qty: 100) - Picked:
LPN00067890(SKU: WIDGET-A, Qty: 100)
Trigger: WMS sends webhook/event with status UPDATED
Zimark Action: ✅ UPDATE MANIFEST with the full new pallet list (Zimark reconciles the difference)
Action: Pallets staged at dock, ready for loading
WMS Order Status: READY_TO_LOAD
Zimark Action: Gate scans pallets, validates against manifest
WMS Order Status: SHIPPED Action: All pallets loaded, truck departs Zimark Action: Manifest status → COMPLETED, proof of load captured
This use case maps to three API calls across the order lifecycle. For the full request/response details and copy-ready code in cURL, JavaScript, and Python, follow the Create and update a Manifest guide. The summary below is about when to make each call and why.
Note: the pallet IDs you send as
assetsdon't have to be coupled to a Zimarker yet; coupling can happen separately, typically during receiving or printing. A pallet is verified at the gate once it carries a Zimarker. See Coupling.
Trigger: WMS order status → UPDATED
Call: GET /manifest/{orderId}: check whether a manifest already exists for this order before deciding to create or update.
Returns: the manifest with its status, gate, and custom fields (assets are read separately via GET /manifest/{orderId}/asset).
Trigger: WMS order status → FULLY_ALLOCATED
Call: POST /manifest
Send: the order ID as identifier (a string), the list of allocated pallet IDs as assets, and the customer name as a custom field. Returns the new manifest's uuid.
Trigger: WMS allocation modified: a pallet is swapped during picking.
Call: PUT /manifest/{orderId}
Send: the full desired asset list. The update is declarative: Zimark reconciles the manifest to match what you send, so a substitution is just the new list with the old pallet removed and the new one added.
- ✅ Manifests created within 5 seconds of WMS reaching
FULLY_ALLOCATED - ✅ Pallet substitutions reflected in Zimark within 10 seconds
- ✅ Zero manifests created for incomplete allocations
- ✅ Customer name correctly populated in 100% of manifests