As part of the ongoing transition from booking to tour terminology, this field has been replaced by active_tour_id, which returns the ID of the driver’s currently active tour as a single value (or null when idle).

Changes:

• A new active_tour_id field is now available on the User resource when the resource is a driver
• The existing active_hailing_booking_ids array field continues to work but is deprecated
• active_tour_id returns a single UUID or null, replacing the array which only ever contained zero or one element

Migration: Replace usage of active_hailing_booking_ids with active_tour_id:

// Before (active_hailing_booking_ids — array, always 0 or 1 elements)
{ "active_hailing_booking_ids": ["550e8400-e29b-41d4-a716-446655440000"] }

// After (active_tour_id — single value or null)
{ "active_tour_id": "550e8400-e29b-41d4-a716-446655440000" }

As part of the ongoing split between bookings and tours as distinct concepts, this filter has been replaced by on_active_tour, which provides the same functionality with naming that better reflects the underlying domain model.

Changes:

• A new on_active_tour boolean filter is now available on the List Users endpoint
• The existing on_active_hailing_booking filter continues to work but is deprecated
• Both filters behave identically — filtering drivers by whether they currently have an active tour

Migration: Replace on_active_hailing_booking with on_active_tour in your API calls:

# Before
GET /api/users?filters[on_active_hailing_booking]=true

# After
GET /api/users?filters[on_active_tour]=true

This field was previously used to configure the frequency at which the next driver would be looked up for marking as preferred during gradual rollout. With the removal of the per_tour gradual rollout mode, this configuration is no longer used - the frequency is now controlled by an environment variable.

Changes:

• The field now always returns null regardless of the stored value
• Providing this field in create/update requests is still accepted but has no effect

Migration: No action is required. The field will continue to be returned in API responses (with the value null) until it is removed.

Instead, you should switch to the dedicated endpoint for tours or bookings.

This property has become obsolete in early 2024 with the introduction of our flexible package tours product, allowing any tour to have arbitrary stops as desired, and hasn’t been used for some time. We are now fully removing it from our API responses.

This change became necessary since depending on the configuration a forced delivery now requires additional data for proofs to be provided, which wasn’t possible with the generic transition.

We normally indicate granular permissions for specific interactions in the permissions object on responses. While the permission to remove a certain package was already indicated, it doesn’t only apply to dropoff tours, and wasn’t in the right namespace to ease API consumption, therefore we are replacing it with this new standardized property.

In early 2024 we have changed the behaviour of our platform to make the distinction between bookings and tours clearer - bookings represent customer demand, while tours are responsible for the (optionally optimized) execution of such bookings by drivers. As a consequence of this, since then drivers cannot directly accept regular bookings anymore, with wide-ranging consequences to the events and flow a booking and a tour can have.

So far, many of our webhook events were shared between bookings and tours however, in the hailing_booking.* namespace. We are replacing these with dedicated events that more closely reflect the actual possibilities and lifecycles of their corresponding data models.

Please update all your webhook receiving endpoints and configurations accordingly to utilize the new events instead:

Booking events

Tour events

Historically, to update a stop’s information you had to also supply the corresponding booking ID, for example at /api/hailing/bookings/:booking_id/stops/:stop_id/metadata. Due to the ongoing split between bookings and tours you would also in the future have needed to call different endpoints depending on whether it’s a tour or booking stop.

To simplify this, we have removed the booking and tour namespacing from endpoints related to editing stop data, linked below. All of the endpoints now follow the route schema /api/stops/:id/[endpoint].

The old routes remain supported for the time being but will be removed in the future.