container.tracking.stopped
Overview
Fired when tracking for a container has been stopped — either because the container lifecycle is complete (e.g. empty returned) or because the container was manually archived by a user.
When This Event Fires
This event fires in two scenarios:
- Automated completion: The report processing pipeline determines that the container's workflow is complete (e.g. the container has reached
EMPTY_RETURNEDand the tracking lifecycle is finished). ThecompletionReasonin the changes object indicates why tracking stopped. - Manual completion: A user manually archives or completes the container from the OpenTrack UI or API.
Payload Structure
{
"event": "container.tracking.stopped",
"data": { /* IContainerVoyageResponse — full container snapshot */ },
"changes": {
"completionReason": {
"previous": null,
"current": "LIFECYCLE_COMPLETE"
}
},
"deliveryAttempt": 1,
"pendingRetries": 4,
"sentAt": "2025-07-19T17:00:00.654Z"
}data object
data objectThe full final state of the container at the time tracking was stopped.
changes object
changes objectContains the completionReason with { previous, current }:
previousis typicallynull(the container was actively tracked)currentcontains the reason tracking was stopped (e.g.LIFECYCLE_COMPLETE,MANUALLY_ARCHIVED, etc.)
Common Use Cases
| Use Case | How to Implement |
|---|---|
| Close out shipment records | When tracking stops, mark the shipment as completed in your TMS or ERP system |
| Final snapshot archiving | Capture the final data payload as the definitive record for the completed container |
| Invoice generation | Use the tracking stopped event to trigger invoice creation for completed shipments |
| Clean up active monitoring | Remove the container from your active monitoring dashboard or alert system |
| Completion analytics | Record the completionReason and final status for transit time and lifecycle analytics |
Updated about 4 hours ago
