Closed Loop Return Update
Overview
ZigZag status and action updates allow retailers to inform ZigZag when a return has been received, processed or graded. This keeps the return timeline accurate and supports reliable claims, operational reporting, fraud prevention and customer behaviour analysis.
Closed Loop Return Update is also referred to operationally as Closed Loop Scans.
What is a Closed Loop Return Update?
A Closed Loop Return Update is an event sent to ZigZag by a retailer, warehouse, WMS, OMS or ZigZag RMS to confirm that a returned parcel has been received and, where applicable, processed.
It closes the loop on the return journey by confirming what happened after the customer sent the parcel back. This may include receipt by the retailer, refund processing, item grading, resale, rejection, destruction or fulfilment.
The customer sends the parcel back. The carrier may scan it. The retailer receives it. The retailer then tells ZigZag: "we have it, and this is what happened next." That update closes the loop.
These updates are sometimes described as Closed Loop Scans, but the update does not have to come from a physical scan. It can be generated by a warehouse receipt, WMS event, OMS workflow, RMS action, customer service action or item-level grading process.
Why this matters?
Closed Loop Return Updates help ZigZag move beyond carrier tracking alone. Carrier scans can be delayed, missed or incomplete. A retailer’s warehouse, WMS, OMS or ZigZag RMS may know the parcel has arrived before carrier data fully confirms it.
- Track the full journey from return initiated to return processed.
- Record the point at which the parcel is received in the retailer’s own operation.
- Capture grading, resale, destruction or fulfilment events after receipt.
- Reduce erroneous claims caused by incomplete carrier scan chains.
- Measure carrier performance against agreed SLAs.
- Measure dwell time between delivery to warehouse and refund processing.
- Monitor customer behaviour and Keep Rate, meaning how much a customer buys compared with how much they keep.
- Train future decisioning models using historical return outcomes at customer and item level.
- Improve fraud prevention, claims handling and operational reporting.
How the process works?
- The return is initiated through ZigZag, the carrier or the retailer journey.
- The customer sends the parcel back.
- The parcel is received by the retailer’s warehouse, WMS, OMS or ZigZag RMS.
- The retailer posts a receipt status back to ZigZag, such as DeliveredToRetailer.
- ZigZag records the updated operational milestone on the return timeline.
- The retailer can then post follow-on actions, such as processed, accepted, rejected, graded, resold, destroyed or fulfilled.
- Where required, the retailer can post item-level outcomes for individual units within the same return.
Supported update options
| Endpoint | Method | Best for | Notes |
|---|---|---|---|
| /api/v1/Returns/ChangeStatus | POST | Marking the return as received by the retailer or moving it to a key operational state | Best for simple closed loop receipt updates such as DeliveredToRetailer. |
| /api/v1/Returns/ChangeAction | POST | Updating the return once the warehouse has processed it | Useful for actions such as Processed, Accepted, Rejected, Resell, Fulfill, or Destroy. |
| /api/v1/Returns/ChangeActionPerUnit | POST | Updating item-level outcomes inside one return | Best when each unit needs its own outcome or processing status. |
| /api/v1/Returns/{returnId}/CustomProperties | POST | Adding retailer-specific fields | Use for grading notes, internal references, claims metadata or other retailer-defined data. |
Change status example
Use this endpoint when the retailer wants to confirm that the parcel has been received back into its own operation
Endpoint: POST /api/v1/Returns/ChangeStatus
{
"orderStatus": "DeliveredToRetailer",
"returnId": "NL000-1-HM61FG6434445",
"returnUniqueIdentifier": null,
"externalStatusCode": null,
"externalReasonCode": null
}
Example return journey
A customer returns three items. The carrier tracking still shows the parcel as in transit, but the retailer’s warehouse has already received it.
The retailer sends ZigZag a DeliveredToRetailer update. ZigZag now knows the parcel is back with the retailer, even if the carrier has not yet sent a final delivery scan.
Later, the retailer sends item-level outcomes:
- Item 1 - accepted and refunded.
- Item 2 - rejected due to wear.
- Item 3 - accepted and returned to stock.
This gives ZigZag a complete view of the return journey and the operational outcome of each unit.
Recommended implementation approach
- Send a receipt status as soon as the parcel is physically received or recognised in the retailer operation.
- Use ChangeStatus for simple return-level milestones such as DeliveredToRetailer.
- Use ChangeAction when the return has been processed at return level.
- Use ChangeActionPerUnit where the return contains multiple items with different outcomes.
- Use CustomProperties for retailer-specific grading notes, internal references, claims metadata or additional audit fields.
- Avoid relying only on carrier scans where the retailer has more accurate warehouse data.
- Keep status names and action names consistent across environments to protect reporting quality.
Data and reporting benefits
Closed Loop Return Updates support more accurate operational reporting because they connect the original return request, the carrier journey, the warehouse receipt and the final processing outcome.
| Area | Benefits |
|---|---|
| Claims | Helps identify when a parcel was received despite a missing carrier scan. |
| Fraud prevention | Improves the historical customer-level data used to spot suspicious return patterns. |
| Carrier performance | Compares carrier SLA delivery events with retailer receipt events. |
| Warehouse performance | Measures dwell time between receipt, grading, and refund processing. |
| Customer insight | Supports Keep Rate analysis and broader customer behaviour monitoring. |
| Model training | Provides better outcome data for future decisioning and risk models. |
Terminology note
Use “Closed Loop Return Update” externally
This is broader and clearer than Closed Loop Scan because the event may come from a scan, warehouse receipt, WMS process, OMS action, RMS update or item-level grading event.
For internal or operational teams, Closed Loop Scan can still be used as a familiar shorthand, provided the technical documentation makes clear that a physical scan is not required.
Summary
A Closed Loop Return Update confirms that a return has reached the retailer and records what happened next. It gives ZigZag a complete, accurate return timeline and supports refund accuracy, claims reduction, carrier SLA measurement, warehouse performance reporting, fraud prevention and customer behaviour analysis.