Workflows
Check OTTO returns: Which returns are still open?
Check open OTTO returns with AI: distinguish announcements, misdirected returns and shipment status to create an evidence-based worklist.
Start by finding OTTO return items with the status ANNOUNCED or MISDIRECTED. Then check separately what the return shipment tracking reports and what your warehouse has actually received. An announced return does not establish that it has been shipped. On OTTO, even the shipment status DELIVERED does not necessarily confirm receipt at your warehouse. The result is a worklist for further checks, not automatic authorisation to issue a refund.
With Backlane, you can read the return and return shipment data that your OTTO account makes available in an AI chat. The documentation explains the connection; the practical guide to analysing marketplace data with AI describes the general workflow. The following prompts are templates and have not been run against a seller account.
Which returns count as open in this check?
For the initial worklist, we consider announced and misdirected returns. ANNOUNCED means that a return has been announced. MISDIRECTED identifies an item mistakenly returned to OTTO. OTTO recommends regularly checking these two states, as described in its official use cases.
“Open” is our working definition here. The interface does not provide a combined status with that name. Items already accepted or rejected are considered separately, even if an internal query about them remains unresolved.
| Return status | What does it tell you? | What should you check next? |
|---|---|---|
ANNOUNCED | The return has been announced. | Is shipment data available, and is warehouse receipt documented? |
MISDIRECTED | The return was mistakenly sent to OTTO. | Check the misdirection details and the appropriate handling process. |
ACCEPTED | Acceptance has been reported. | If there is a query, check the acceptance reason and, where relevant, the refund receipt. |
REJECTED | Rejection has been reported. | If further clarification is needed, review the rejection reason and available evidence. |
The Returns interface works at item level. If someone orders three units of the same product, this creates three individually identifiable position items. Count items and orders separately. One returned item does not turn the entire order into a return.
How do you create a complete list of open items?
First select the correct OTTO connection. Then retrieve every results page for both open status groups. Filtering for only the most recent orders would be inappropriate here: an older order may still have an open return.
The occurredTime field records the last change to the return status. It is neither the order date nor necessarily the date of the first return announcement. Sorting by it helps you review the list; it does not establish that a processing deadline has been missed. The fields and query parameters are defined in the Returns v3 specification in the OTTO API Index.
Create a read-only worklist of open returns for my OTTO connection
[connection name]. Do not change any data.
Use the Returns interface to retrieve ANNOUNCED and MISDIRECTED
separately, including every results page for each status.
Do not restrict the selection to the most recent orders.
Match items using salesOrderId and positionItemId.
Count unique items and affected orders separately.
For each item, show a local reference, return status and
occurredTime as the time of the last status change.
Within each status group, sort the oldest changes first.
Retain the mapping to the original identifiers for the next check.
Do not display names, addresses or contact details.
State the source, retrieval time and completeness of each status group.
Flag missing timestamps, conflicting matches and retrieval errors.
A partial retrieval is not a complete overview.
The result shows which items are currently reported in these states. It does not reconstruct a historical end-of-day position. A successful query with no results also means something different from a failed request.
What does shipment tracking tell you about a return?
Return shipment tracking describes transport. It provides its own states: ANNOUNCED, ON_THE_WAY and DELIVERED. ANNOUNCED does not establish that the parcel has been handed to the carrier; ON_THE_WAY reports that handover.
Take particular care with DELIVERED: according to the OTTO ReturnShipments documentation, the parcel may still be in its final delivery phase or at a parcel centre. This state is based on a carrier scan. Compare it with your goods receipt records before interpreting it as “goods received”.
Return status and shipment status therefore belong in separate columns. Join the data using the order and the specific item: salesOrderId and positionItemId in the return correspond to salesOrderId and salesOrderPositionItemId in the return shipment. Matching product names are not enough. A shipment can contain several items, and multiple tracking numbers are also possible.
How do you investigate a case that needs attention?
Take a local reference from the first list and add the associated return shipment data. A known returnShipmentId allows a direct lookup. Alternatively, use the combination of carrier and tracking number.
Tracking number lookups have a limited time window, however: OTTO specifies 30 or 42 days from announcement, depending on the carrier, and up to twelve months when using the return shipment ID. A missing result therefore does not prove that no parcel was in transit. These limits are also described in the ReturnShipments documentation.
Run a read-only check of return item [local reference] from our
worklist in OTTO connection [connection name].
Use its associated original identifiers. Retrieve the known
returnShipmentId or the available combinations of carrier
and return tracking number.
Verify the match using salesOrderId and the position item ID.
Do not invent identifiers; list uncertain matches separately.
Show return status and shipment status separately. Determine
the latest shipment state using the supplied occurredOn time,
not the order of the list. State the source and retrieval time.
Output: documented observation, missing evidence and next manual check.
DELIVERED alone does not prove receipt at the warehouse.
Missing tracking is not evidence that no return took place.
Do not accept or reject a return, issue a refund or send a message.
Do not display buyer data.
What does a useful worklist look like?
Fictional example: A seller checks three return items. References R1 to R3 are local example identifiers only.
| Reference | Observation | Next check |
|---|---|---|
| R1 | Return ANNOUNCED, shipment ON_THE_WAY | Continue monitoring transport; warehouse receipt is not established. |
| R2 | Return ANNOUNCED, shipment DELIVERED, warehouse status unknown | Compare goods receipt records with the actual delivery evidence. |
| R3 | Return MISDIRECTED, no unambiguously matched return shipment | Clarify the misdirection using the available OTTO details. |
R2 warrants a targeted check, but not automatic acceptance. For R3, the starting point is the misdirection, not an invented shipment history. The urgency of a case also depends on confirmed deadlines and your internal responsibilities.
For each case, record the documented observation, the missing evidence and the next person responsible. This lets AI help prepare return handling. Inspecting the goods, deciding the outcome and making any write operation remain separate steps.