Put the plan into practice
Explore the decisions, examples and acceptance checks behind this work.
Separate dispatch, shipment records and carrier tracking
A customer can receive a parcel while Magento still shows an unshipped order, or Magento can show a shipment while the carrier has not yet scanned it. These are different states in different systems. Midoriweb starts by identifying which event is missing and which system is expected to supply it.
Record one order, the external fulfilment reference, the Magento shipment record if present and the tracking identifier. Establish whether the problem affects shipment creation, tracking attachment, customer notification or later carrier progress. A generic “tracking not working” report can otherwise send the investigation to the wrong integration.
If the warehouse never received the order, begin with the ERP and WMS order-sync guide. This article follows the return journey from fulfilment to Magento and the customer.
Document who owns each fulfilment event
Define which system confirms dispatch, creates the Magento shipment, assigns tracking and sends the customer email. Some architectures keep those responsibilities together; others divide them between a WMS, shipping platform and Magento. Duplicate ownership can create repeated shipments or notifications, while missing ownership leaves a gap.
The event should have a clear business meaning. A label being printed does not necessarily mean the parcel has left the warehouse. A carrier accepting electronic data is not necessarily a physical scan. Customer wording should reflect the evidence available rather than promise progress that has not occurred.
Midoriweb’s WMS integration service can help define those boundaries. The interface specification should describe the event, identifiers, quantities and expected state transition, not merely the endpoint being called.
Trace the fulfilment response to the original order
Compare the external order reference with the Magento identifier used by the integration. A store’s visible order number and an internal entity identifier are not automatically interchangeable. The receiving endpoint and mapping should determine which reference is required.
Check the website or channel context when several storefronts share one warehouse system. Similar-looking references can become ambiguous if the integration drops a channel prefix or assumes one global numbering scheme. Stable mapping should be established when the order is exported and reused on the return path.
Preserve a redacted sample payload and its processing outcome. The useful evidence shows that a specific dispatch event was matched to a specific order, not simply that the connector was online at the time.
Review line quantities and partial fulfilment
Shipment creation should reflect the items and quantities actually fulfilled. Partial shipments, split warehouses and products with different fulfilment behaviour need explicit handling. A connector that assumes every dispatch completes the whole order may work for simple cases and fail as soon as one item is backordered.
Compare item identifiers as well as product SKUs. The same SKU can appear in a context where line-level options or relationships matter. Verify the installed API’s requirements and the integration’s mapping rather than guessing the order-line identity from product text.
Adobe’s shipment API tutorial illustrates shipment creation and optional tracking data. Real integrations must account for their own product types, partial fulfilment and existing order state; the tutorial is not a complete specification for every warehouse workflow.
Check tracking data and carrier mapping
A tracking number can be present but unusable if the carrier code, title or link-generation behaviour is wrong. Compare the source value with the Magento record and the customer-facing link. Remove accidental whitespace or formatting only through a documented transformation that preserves the actual identifier.
Carrier progress may be managed outside Magento. Establish whether the store is expected merely to provide a tracking link or to import detailed delivery events. Do not describe absent scan updates as a Magento sync failure if that functionality was never part of the integration.
Test the link using a suitable authorised example and verify where it leads. Customer-facing links should not expose internal warehouse URLs or require staff credentials. If the carrier has not yet recognised the parcel, the message should set a clear expectation without inventing a delivery status.
Handle duplicate and delayed dispatch events
Fulfilment systems may retry notifications after timeouts. The integration must recognise an event already applied and avoid creating another shipment or sending repeated messages. Determine how the external dispatch reference is stored and used for reconciliation.
A timeout does not prove that shipment creation failed. Before replaying, check whether the intended shipment already exists and whether only the acknowledgement was lost. Repeating the operation without that check can produce inconsistent quantities or unnecessary customer communication.
Delayed events also need state-aware handling. An order may have been changed, cancelled or manually processed since the original event. The connector should surface the conflict for review rather than blindly force the old event into the current state.
Diagnose notification separately from shipment creation
If Magento has the correct shipment and tracking but the customer received no email, follow the notification path independently. Check whether the integration requested notification, whether the template rendered and what the transport recorded. Our order email guide explains that sequence.
Avoid resending all shipment events simply to trigger missing emails. That mixes two different recovery actions and may duplicate business records. A targeted message retry should be based on the existing verified shipment state and the intended customer communication.
Review message content as well as delivery. The correct order, items, tracking link and recipient need to be present. A delivered email pointing to another shipment or an unusable link is not a successful customer outcome.
Reconcile and recover the affected set
Build a list of affected dispatch events with their last confirmed stage: source created, delivered, shipment applied, tracking attached and notification sent. This makes it possible to select the appropriate repair for each record rather than replay an entire day’s fulfilment indiscriminately.
Test the correction on a controlled sample, including a partial shipment and a repeated event where relevant. Verify Magento quantities, warehouse records and customer-facing information afterwards. Preserve the original identifiers and recovery notes so operations can explain the result later.
After the backlog is repaired, observe new dispatches through the normal path. Monitoring should identify missing acknowledgements, rejected mappings and events waiting for manual review. A one-off reconciliation is not enough if the next warehouse cycle recreates the same gap.
What to send Midoriweb
Provide the systems involved, affected stage, first failure time and one redacted order and dispatch reference. Explain whether shipments are created manually or automatically and whether partial fulfilment is common. We can then scope the relevant connector, Magento and notification checks.
Our ecommerce integration support focuses on the complete operational hand-off. The deliverable should explain the failure boundary, safe recovery and prevention of duplicate processing, with clear limits where a carrier or warehouse service controls the remaining outcome.
Shipment and tracking questions
Does a tracking number prove dispatch?
Not necessarily. It may be created before physical handover. Agree which event represents dispatch and use accurate customer wording.
Should a failed callback be replayed immediately?
First check whether the shipment was already created. The acknowledgement may have failed after the business action succeeded.
Why does a partial order stay open?
Remaining unfulfilled quantities can legitimately keep an order from its final state. Compare the actual line-level fulfilment before forcing a status change.