The tour stats notification now delivers the tour’s stats itself, so an integration can apply them the moment they arrive instead of fetching them after every notification.

Until now tour.stats_updated¹ only told you that a tour’s statistics or route estimate had changed, and you called Fetch stats for tours² to learn the new values — one round trip per notification, for every consumer. From this release the notification carries what that call would have returned for the tour, and the fetch can go.

What is in the payload

The event gains a stats object with the fields of a stats endpoint response item: the package counts and weight, the stop counts, the time the driver spent on the tour, and the estimated distance and duration of its route. Only the tour’s id is left out, since the notification names the tour already.

{
  "tour_id": "5b2d1a0e-…",
  "service_area_id": "9f1c4e77-…",
  "status": "en_route",
  "stats": {
    "packages_count": 4,
    "packages_weight_grams": 6200,
    "packages_for_destination_count": 4,
    "packages_delivered_to_destination_count": 1,
    "packages_failed_to_destination_count": 0,
    "stops_count": 5,
    "stops_failed_count": 0,
    "duration_seconds": null,
    "estimated_distance_meters": 18420,
    "estimated_duration_seconds": 2710
  }
}

The values mean the same as on the endpoint. duration_seconds is null until the tour is completed, and the estimated distance and duration are null while the route has no estimate — for example when a stop cannot be reached by road.

Please adjust your integration

If your integration reacts to the tour stats notification by calling the stats endpoint, please switch it to the delivered stats. Every avoided round trip saves your integration a request per notification and reduces the load on the platform for everyone, and it puts the stats in your hands the moment they are known. The endpoint stays as it is for everything else, such as loading the stats of several tours at once.