Shipment tracking
Match a conversation to the right order and read its carrier events. Keep the parcel, direction and time of each observation visible.
Try the exampleWhere is this customer's parcel?
| Example parcel | Direction | Last observation | Review |
|---|---|---|---|
| Parcel A | Outbound | Carrier event available | Check event time |
| Parcel B | Outbound | No events returned | Coverage unknown |
| Parcel C | Return example | Separate journey | Do not mix directions |
Result
A dated parcel history and an explanation for the support reviewer.
What needs a person
Missing events are not proof that a parcel is stationary. A tracking read does not authorise a refund or promise a delivery date.
Company notes
The customer's order, shipment match and rules for interpreting carrier events.
AI agent
Read the matched parcel events and prepare a dated explanation, keeping gaps and return journeys separate.
Customer care AI agent
Connected tools
Exact commerce order, warehouse shipment and available carrier events
Build notes
Carrier history is available to the support workflow through a bounded read connection. Reads have timeouts, retry limits and provider cooldowns. A stored event keeps its observation time rather than appearing newly observed on each read.
The documentation shares the method, not the private application's source code.
Read the build notes ↗What we checked
Reviewed
Functionality tested
The deployed connection returned real outbound events from several carriers. Empty responses remained explicit. Return-direction handling passed fictional tests, but a real return journey was not independently verified.
Where it stops
Read-only shipment evidence. Not universal carrier coverage, autonomous claims handling or proof that the customer received a parcel.
Evidence remains private.