We are introducing structured failure reasons on stops. When a dispatcher or driver fails a stop, they can now pick the reason from a predefined, stop-type-specific list – for example, Recipient is unavailable or Location is closed – and optionally add a short free-text comment. The selected reason and comment are stored on the stop and visible on the booking to everyone involved.

Support for failure reasons will be rolled out across the API, Dashboard, and driver apps over the coming weeks.

Until now, when a stop couldn't be completed, there was no consistent way to capture why. Driver relied on free-text notes or out-of-band processes, making it hard to spot patterns or give customers a meaningful explanation. Standardized reasons turn every failed stop into structured, comparable data — useful for operations, analytics, and customer communication.

Failure reasons will plug into the upcoming "Fail with outcome" experience for dispatchers, where picking a reason becomes the first step of a full recovery flow.

As part of a larger rework of the driver experience, the Active tour screen in the driver app is gaining a configurable set of labels – similar to how the Off-route display already works today. Tenants will be able to tailor what information drivers see at a glance while a tour is in progress, picking from a rich set of label types to match their operations.

Support for active tour labels will be rolled out across the API, Dashboard, and driver apps over the coming weeks.

The Dashboard is gaining a more accurate view of tours: instead of straight-line connections between stops, it will display the actual route a driver follows on the road network. Operators get a clearer picture of where tours go in practice and whether routing matches operational expectations.

Support for real tour routes will be rolled out on the Dashboard over the coming weeks.

When creating bookings or tours, integrators can now pick the service by a human-readable key – chosen by an admin when the service is set up (like “default” or “express”) – instead of looking up its UUID. This makes integrations faster to set up and less error-prone.

We have introduced a 500-character limit on the additional information field on bookings and stops, and on the additional line field on stops. The cap helps keep notifications to drivers and customers reliable, even for bookings with very long notes.

We've moved package failure reasons onto a unified Reasons API that handles all reason categories (stop failures, package failures, and more to come) in one consistent format. The legacy endpoint will continue to work until September 16, 2026. If your integration uses it, please refer to the migration guide for details.