The tour ETA notification now delivers the recalculated estimates itself, so an integration can apply them the moment they arrive instead of fetching them after every notification.

Until now tour.etas_recalculated¹ only told you that a tour’s ETAs had changed, and you called Fetch estimated arrival times for stops² 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, and the fetch can go.

What is in the payload

The event gains a route_estimates object with a stops array, in exactly the shape the estimates endpoint returns: for every stop still expecting an arrival, in route order, its id, expected_arrival_at and waiting_time_seconds. Completed stops are left out, since their estimates no longer change.

{
  "tour_id": "5b2d1a0e-…",
  "service_area_id": "9f1c4e77-…",
  "route_estimates": {
    "stops": [
      { "id": "c1786e3e-…", "expected_arrival_at": "2026-09-30T09:41:12.000Z", "waiting_time_seconds": 0 },
      { "id": "8ff7d0a0-…", "expected_arrival_at": "2026-09-30T10:02:47.000Z", "waiting_time_seconds": 180 }
    ]
  }
}

When route_estimates is null, fetch

The attribute is null in two situations: on large tours — more than 40 stops still expecting an arrival — where the full list would exceed the size a single notification can carry, and when the estimation was not available at the time of publishing. In both cases treat the notification as you do today and fetch the estimates from Fetch estimated arrival times for stops² (or Fetch estimated arrival times for multiple bookings at once³ for several records at once). A non-null route_estimates is always complete, so the rule is simple: apply it when it is there, fetch when it is null. The same tour can move between the two as stops are added or completed, so handle both paths.

The booking notification is unchanged

booking.etas_recalculated⁴ keeps its payload as it is. Its unfinished_stops_info list already carries the next ten unfinished stops with their type, position and ETA, and that remains the place to read a booking’s estimates from — nothing to migrate there.

Please adjust your integration

If your integration reacts to the tour ETA notification by calling the estimates endpoint, please switch it to the delivered route_estimates and keep the call only as the fallback for the cases above. Every avoided round trip saves your integration a request per notification and reduces the load on the platform for everyone, and it puts the estimates in your hands the moment they are known.