> For the complete documentation index, see [llms.txt](https://docs.lionparcel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lionparcel.com/api/api-reference-en/another-journey/return-management.md).

# Return Management

### A. **Overview**

Lion Parcel provides an automatic mechanism **Return Management** to handle shipments that cannot be completed and must be returned to the sender.

When a shipment fails to be delivered, is rejected, canceled, or must be returned, the Lion Parcel system will automatically:

* Update the shipment status according to operational conditions.
* Generate **a new AWB** (return waybill) for the return trip.
* **Link that new AWB with the original AWB**, so the entire journey history remains visible and traceable via the Tracking API.

The main purpose of this mechanism is to ensure the return process is **transparent**, **automatic**, and **easy to track** by the client.

### **B. When the Return Process Occurs**

The return process can occur due to the following operational conditions:

**1. RTS (Return to Shipper) :** The package is returned directly to the original sender.

**2. RTSHQ (Return to Headquarter) :** The package is returned to Lion Parcel's central hub before being routed back to the sender.

**3. CNX after REJECTED :** The package is canceled due to rejection by the cargo airline or x-ray inspection results **before** reaching the destination city.

### **C. What the Lion Parcel System Does in Return Cases**

For all of the above conditions, the system will automatically:

1. Mark the original AWB with a return/cancel/return-HQ status.
2. Generate **a new AWB** for the return process.
3. Link the original AWB and the return AWB so the client can still perform end-to-end tracking **end-to-end** without losing visibility of the journey.

This prevents having separate or non-sequential tracking data.

### **D. Tracking API Parameters Related to Return**

When a shipment enters the return process, the Tracking API will show the following important parameters:

**Key Parameters**

| Parameter              | Type   | Description                                                                                                                  |
| ---------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------- |
| **status\_code**       | String | The latest main status of the shipment.                                                                                      |
| **stt\_journey\_type** | String | Indicates the type of AWB journey (return, cancel, reroute). This information may change according to operational processes. |

### **E. stt\_journey\_type Values Indicating Return**

The following values indicate that the shipment is in the process of return or cancellation:

* `return`
* `cancel`
* `reroute-cancel`
* `returnhq-reroute`
* `reroute-returnhq`
* `reroute-return`
* `returnhq`
* `return-reroute`
* `return-returnhq`
* `return-reroute-reroute`
* `return-returnhq-reroute`
* *(and other combinations according to operational conditions)*

#### **Important Note:**

* This list **is dynamic**. As long as the value **contains the keyword: return**, **returnhq**, or **cancel**,\
  then the shipment must be considered as **Returned Item** by the client system.

#### **F. Implementation Guide for Clients**

So that the client system can correctly handle returns, implement the following logic:

**1. Detect Return Indicators**

The system must be able to read the value **stt\_journey\_type** that contains: `return`, `returnhq`, or `cancel`.

2. **Mark the Shipment as Returned Item**

When the Tracking API returns that value: Categorize the shipment as **Returned Item** in your OMS/WMS/platform.

3. **Continue Tracking Using the Original AWB**

* Client **does not need to track the new AWB separately**.
* Lion Parcel will automatically link the return AWB with the original AWB
* Use **the original Shipment ID/AWB** to view the entire journey including the return process.

#### G. Example Tracking API Response (Return Case)

```json
{
  "row": 16,
  "datetime": "2025-02-18T14:12:03+07:00",
  "status_code": "BKD",
  "current_status": "BKD",
  "location": "CGK",
  "city": "JAKARTA",
  "remarks": "YOUR PACKAGE HAS BEEN PROCESSED BY LION PARCEL AGENT JAKARTA, KEDOYA SELATAN, KEBON JERUK, WEST JAKARTA",
  "attachment": [],
  "updated_by": "SYSTEM",
  "updated_on": "2025-02-18T14:12:03+07:00",
  "stt_journey_type": "return-reroute",
  "ref_stt_number": "77LP1739862283819",
  "shipment_id": "C1OIZPBA",
  "total_tariff": 7000,
  "reason": "",
  "problem_reason_code": "",
  "chargeable_weight": 1,
  "total_gross_weight": 0.5,
  "total_volume_weight": 0.1,
  "is_insurance": false,
  "insurance_rate": 0,
  "pieces": 1,
  "proof": {
    "attachment_signed": [],
    "latitude": 0,
    "longitude": 0,
    "relation": "",
    "name": ""
  }
}

```

### H. Example usage of journey\_type  **HOW TO USE**

In the Tracking API, the parameter ;\
1\. **`status_code`** \
2\. **`stt_journey_type`** \
represents related shipment statuses. To read and link both statuses, the client only needs to use **one primary identity** as a reference, namely **`shipment_id`** or **`ref_stt_number`**, depending on the API used.\
\
For clients using **the Create Shipment API (Pickup & Drop-off Collection)**, the system will return **`shipment_id`** as the main response when creating an order. \
\
For clients using **the STT Booking for Client API**, the system will directly return **`ref_stt_number`** as the airwaybill number. \
\
**Clients do not need to use both simultaneously**, because all shipment status changes, including the return process and AWB updates, can still be traced using the chosen primary identity.\
\
**STATUS INTRODUCTION**

status\_code values

ON GOING STATUS

* `BKD`
* `PUP`
* `STI-SC`
* `STI`
* `BAGGING`
* `CARGO PLANE`
* `CARGO TRUCK`
* `CARGO TRAIN`
* `CARGO SHIP`
* `TRANSIT`
* `STI-DEST`
* `STI-DEST-SC`
* `PICKUP TRUCKING`
* `DROPOFF TRUCKING`
* `STO-SC`
* `INTHND`
* `INT-STI`
* `OCC-EXP`
* `OCC-IMP`
* `DEI`
* `DEX`
* `STT REMOVE`
* `SHORTLAND`
* `MIS-ROUTE`
* `STT ADJUSTED`
* `HAL`
* `ODA`
* `MISSING`
* `DAMAGE`
* `NOT_RECEIVE`
* `OCC`
* `IN-HUB`
* `OUT-HUB`
* `CARGOSHIP`
* `KONDISPATCH`
* `STLDISPATCH`
* `HND`

FINAL STATUS

* `POD`
* `CNX`
* `RTS`
* `RTSHQ`
* `REROUTE`
* `CLAIM`
* `STT ADJUSTED AFTER POD`
* `SCRAP`

**EXPECTED STATUS**

stt\_journey\_type values

EXPECTED DELIVERED TO RECEIVER

* `"" (empty)`
* `reroute`
* `reroute-reroute`

EXPECTED RETURN TO SELLER

* `return`
* `cancel`
* `reroute-cancel`
* `returnhq-reroute`
* `reroute-returnhq`
* `reroute-return`
* `returnhq`
* `return-reroute`
* `return-returnhq`
* `return-reroute-reroute-reroute`
* and so on...<br>

**CONCLUSION**

If stt\_journey\_type contains:

* `return`
* `returnhq`
* `cancel`

<mark style="color:$primary;">**Then shipment should be treated as RETURN**</mark>.

**EXPLANATION**\
\
`""` (empty) → Normal journey of the package to the receiver.

`reroute` → Correction of a wrong delivery destination during the initial booking process.

`return` → Return of the item to the sender (Return to Shipper) for certain reasons.

`returnhq` → Return of the item to Lion Parcel HQ for certain reasons.

`cancel` → Shipment canceled (usually after a rejected status or rejection from cargo).

`return-reroute` → The package is returned to the sender and the destination is corrected during the RTS booking process.

`reroute-return` → A destination correction was made during the initial booking, then the package was returned to the sender.

`reroute-cancel` → A destination correction was made during the initial booking, then the shipment was canceled.

`returnhq-reroute` → The package is returned to Lion Parcel HQ and a destination correction is made during the RTSHQ process.

`reroute-returnhq` → A destination correction was made during the initial booking, then the package was returned to Lion Parcel HQ.

`reroute-reroute` → A destination correction occurred more than once during the initial booking process.

**and so on… → The**v `stt_journey_type` **can evolve dynamically following combinations of operational processes** (`reroute`, `return`, `returnhq`, `cancel`).

### **I. Conclusion**

Lion Parcel's Return Management mechanism ensures that every return event is recorded completely, transparently, and easily traceable. When a return occurs:

* The system automatically creates a new AWB for the return process.
* That new AWB is linked to the original AWB.
* The client only needs to use **the original Shipment ID/AWB** to view the entire journey, including the return.
* The Tracking API becomes *a single source of truth* in detecting return, cancel, and reroute scenarios.

### **I. Main Principle for Clients**

A shipment should be considered **Returned Item** if **stt\_journey\_type** contains one of the following words:

* **return**
* **returnhq**
* **cancel**

Variants may differ depending on operational conditions (for example: `returnhq-reroute`, `return-returnhq`, `reroute-cancel`, etc.). As long as any of the keywords appear, the shipment is in the flow **return**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lionparcel.com/api/api-reference-en/another-journey/return-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.