The new active_tour_labels and active_stop_labels configuration options allow you to control which labels are shown to drivers during an active tour, using the same label types available for the off-route display:

• Priority indicators
• Tour name
• Driver earnings
• Total tour distance
• Custom metadata on tours and stops
• Expected arrival time windows on stops

The scheduled_at label and the distance_to_first_stop distance variant are not available for active tours, as they are not relevant once a driver is already en-route.

Configuration is available via the existing tour display admin APIs:

Webhook events

The following webhook events now include stop_type: "return" as a possible value in their payload. If your integration inspects the stop_type field, make sure your webhook handlers accept this new value:

Service configuration

Services can now be configured with return stop settings through the admin API. When return is included in a service’s stop_types array, the following configuration fields become available:

• return_stop_duration_seconds — expected duration at the return location (default: 300 seconds)
• return_label_translations — customizable label for the return stop in multiple languages
• return_stop_default_maximum_driver_distance_meters — geofencing distance for the return location
• return_stop_default_auto_arrival_distance_meters — distance for automatic arrival marking

Creating and managing return stops

Return stops can be included when creating bookings or inserted into existing tours and bookings. The stop type on existing stops can also be changed to or from return via the update stop properties endpoint.

The public service listing also reflects whether return is enabled as a stop type:

Unlike UUIDs, service keys are immutable, descriptive identifiers (e.g., default, express) that stay stable across different tenants and between test and production environments — no need to look up the exact UUID for a specific service on each tenant. We recommend using service_key for new integrations where possible.

The service object in booking responses now includes a key field alongside the existing id, and you can discover all available service keys via the Services configuration endpoint.

Important: service_id and service_key cannot be combined in the same request. If both are provided, a validation error will be returned. When neither is given, the tenant’s default service is used — this behavior is unchanged.

New active_tour_id field

A new active_tour_id field is now available on the Users endpoint when the returned user is a driver. It’s a nullable field representing the driver’s current active tour and it’s a replacement for the active_hailing_booking_ids array field, which is now deprecated.

⚠️ Breaking Change - Failure code renames ⚠️

The following failure codes have been renamed:

• The active_driver_on_a_booking failure code returned by the Block User endpoint has been renamed to active_driver_on_a_tour.
• The on_active_booking failure code returned by Send Driver Offline endpoint has been renamed to on_active_tour.

If your integration handles these specific failure codes, please update accordingly.

The verification value is provided as an argon2id hash. The backend only validates that the value is a structurally valid argon2id hash — it never sees the plaintext. The driver app collects input from the recipient and verifies it locally against the hash.

Important: While hashing obscures the plain text, it does not keep the value secret. Values with small problem spaces — such as birth dates (~37,000 possible values in the last 100 years) or short numeric PIN codes — can still be brute-forced. Argon2id makes this computationally harder, but these values should not be considered secret.

The choice of argon2id parameters is up to the requestor. The RFC 9106 “first recommended” configuration is a good starting point.

When using the date value type, the date must be formatted as YYYY-MM-DD (ISO 8601 calendar date) before hashing with argon2id.

This new content type can be used when creating or updating stops:

Data retention: Once a booking or tour is operationally completed (reaches done, paid, or cancelled state), all verification content values are automatically anonymized. The value field is replaced with a random argon2id hash. The content item itself is preserved as a record that verification was requested.

Instruction templates with variables

Stop instructions provide a convenient way to add common tasks at stops without having to provide the full custom content schema payload. You can see available instruction templates via the dedicated endpoint:

Two new instruction templates are now available that use verification content with dynamic variables:

• birthday_verification — requires a birthdate_argon2id variable (the recipient’s date of birth, hashed with argon2id)
• pin_code_verification — requires a code_argon2id variable (a delivery PIN code, hashed with argon2id)

Instructions can now be passed as objects with a key and variables field, in addition to the existing plain string format. Existing plain-string instructions continue to work unchanged.

{
  "instructions": [
    { "key": "birthday_verification", "variables": { "birthdate_argon2id": "$argon2id$..." } }
  ]
}

Each template’s required variables and their schemas can be introspected via the variables_schema field on the list available instructions endpoint shown above.

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

Previously, invited users were always assigned to the organization manager’s first managed organization. Now, organization managers can choose the target organization from their managed organizations list.

If no organization_id is provided, the behavior remains unchanged—the invited user defaults to the organization manager’s first managed organization.

This ensures that integrations relying on this webhook receive consistent notifications for all bookings, regardless of whether they were part of the tour from the start or were added mid-route.

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.

• Old response: collection_errors: { "2": [{ external_id: ["has already been taken"] }] }
• New response: collection_errors: { "2": { external_id: ["has already been taken"] } }

To keep things consistent, we’ve moved the endpoint for setting preferred drivers to be in the tours and bookings namespace, deprecating the existing endpoint that is under the hailing_bookings namespace.

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

Before, this was a combination of preferred drivers on a tour, managing organizations and a driver from an organization having accepted a tour. This was a bit hard to see through in different operational scenarios and hence was leading to confusion, which we intend to address by having just one, simple and transparent rule for the visibility going forward.

This means that if you want to show a booking or a tour to a certain organization, you will have to set that organization as one of the managing organization.

Previously, we would base the visibility rule also off the pending driver requests, as well as off the current tour’s driver’s organization.

When creating a place, you can now pass an optional external_id string. You would normally set this to the ID of that location in your source system.

In contrast to other, location-specific attributes that require to fork a place instead of updating in place to avoid impacting historical transactional data, you can update the external_id in place (and also via Fork)

The external_id becomes indexed by our search index so you can search by it, and you can also use it as a filter on the list endpoint.

This functionality becomes particularily useful if you combine it with the newly extended corresponding external_id functionality when creating bookings.

When you create a booking, you can pass an external_id alongside each stop’s attributes. When given, we will look up the most recently created, non-archived place that belongs to the same customer and assign that to the stop.

When such a place does not yet exist, we will automatically create it instead using the address data given, and on the next booking creation it will be re-used as described above.

Please note that we do not update a previously created, matching place. If you want to update the location address data of a place, in our system that is handled as a new place via the fork mechanism, to keep historical transactional records correct.

You have three options if you want to ensure changed location data get propagated into a place:

• Change the external_id on your side based on the new location
• Remove the external_id on existing places with old location data
• Archive existing places with the same external_id

Any of these will trigger a new place to be created on the next booking creation event based on the location data given on the stop at the time. You can also omit latitude & longitude if you want to utilize our Geocoding features when you do not have GPS coordinates for your location in your system.

The same functionality is also available on the endpoints for adding individual stops into existing bookings and tours:

Together with the new booking lifecycle events, we’ve added new booking’s stop lifecycle event webhooks.

Additionally, we’ve enriched the existing booking.etas_recalculated webhook with the customer ID property, as well as the ETA info regarding the next 10 unfinished stops.

The publication of these webhooks is based off on the lifecycle of the underlying tour(s) and their stops used to complete the booking.

This can also be used with our webhook filtering feature to narrow down certain notifications to specific service areas, for example if you want to roll out an integration only gradually across certain service areas.

The updated messages are the following:

This feature allows easier integration of external systems for booking management with MotionTools, by allowing you to correlate a booking ID on the other system with booking data stored and published via MotionTools, as the booking procedes through it’s lifecycle.

This property will be returned only on bookings fetched via standard and compact views. You can also filter by the external_id on the bookings list.

The property is also included in the CSV export of the bookings.

We have also extended all our booking-related webhooks to contain the external_id when present. This allows you to more easily reference the booking on your side against your own identifier without having to store our booking ID alongside it and match them.

1. Never – Customers cannot cancel their bookings.
2. Before dispatch – Customers can cancel if none of the stops have been dispatched into a tour - this is the default.
3. Before approaching – Customers can cancel if none of the dispatched stops have reached the “approaching” status.
4. Before arrival – Customers can cancel if none of the dispatched stops have reached the “arrived” status.

This new functionality gives you more control over the booking services you offer to your customers.

You can configure the cancellation_policy via our usual service admin API endpoints:

The ability to cancel a specific booking in its current configuration and status is always indicated via the available_transitions property of our bookings payload.

Configuring this via our admin dashboard is also coming soon.

The new webhook is supposed to replace the usage of the very broad tour.modified webhook for cases when you’re interested in getting notified about tour earnings update.

This complements the corresponding feature we’ve announced back in May where this was already made possible more easily for partially_dispatched bookings.

Let’s go through some examples to outline some of the different scenarios. We’ll consider a booking with stops A and B, which are dispatched into a single tour:

Admin cancels before driver arrives at one of the stops

• The dispatched stops get removed from the tour
• The tour is empty and cancelled
• The original booking stops are cancelled
• The original booking is cancelled

Admin cancels after a driver arrived at a stop

• The arrived tour stop A will be marked as failed
• We detach the tour stop A from the booking stop A
• The tour stop B is removed from the tour
• The tour is completed and in paid status
• The original booking is cancelled

Admin cancels after a driver completed or failed a stop

Assuming the driver already completed the tour stop A and is now approaching the tour stop B

• The already completed tour stop A remains done and on the tour
• The corresponding booking stop A remains done
• The second, approaching stop B is removed from the tour and is cancelled on the booking
• The tour is completed and in paid status
• The original booking is cancelled

When the driver fails stop A the behaviour is the same except that of course the stop will now be in failed status both on the tour and booking, instead of done

Overall, the behaviour is the same as for partially_dispatched bookings or bookings that have their stops dispatched into multiple tours - but the rules will accordingly apply to all related tours and stops.

Instructions are pre-defined content that is attached to the stop, providing additional details about things to do for the driver at the stop - for example verifying the recipient’s age. You can see available instructions through the dedicated endpoint:

You can still provide your own content for the stops, alongside instructions. In such a case, the content for the instruction will be appended to the provided content.

In MotionTools when a driver goes online in the driver app as well as while they update their location while they’re online we constantly check their location against the service areas defined for the corresponding tenant.

When the driver moves between service areas we will assign them to the new area automatically. This leads to them showing up in the operations page of a service area in our dashboard as well as giving them the ability to see pickable and scheduled tours for the corresponding service areas.

We have now introduced the ability to assign drivers to one or more specific service areas. If a driver is assigned like this we won’t change their service area in the way described above anymore if the service area matching their current location is not assigned to them.

When a driver is not assigned to any specific service areas, the behaviour remains as it was before - a driver can enter any service area available on the tenant.

The corresponding API endpoints for managing assigned driver service areas that were introduced are:

The feature will soon also be available on our admin dashboard.

Upon regular booking creation we now allow customers and admins to pass an optional tip request payload. The contained fractional amount and currency code will be persisted on the booking.

We also indicate this value on the standard booking response when present.

At this time this value is simply being stored and returned, no further features are available on our platform for further usage - similar to our tour earnings mechanism, this feature simply provides a way to provide and store the data, and further processing needs to be implemented as needed via our API and other integrations.

So far, changing the requested capabilities wasn’t allowed after initial creation of a booking or tour.

Especially in the case of tours this was a bit limiting as a tour might be modified and extended during planning before being given to drivers the required capabilities for doing the tour might change - for example, a simple tour might suffice a bike vehicle, but dispatching more stops from other bookings into the same tour might make a car necessary.

Support for updating those is also soon coming to our web dashboard.

So far the booking CSV export feature was available only to the admin and organization manager roles - we have now also made this availble to customers.

Support for this has also been added to our dashboard.

Our existing managing organizations feature allows scoping the visiblity of bookings and tours to certain organizations - only drivers and organization managers on these organizations (in addition to explicitly added preferred drivers) will be able to see such bookings and tours.

This functionality is useful to scope access and operations to certain operational sub-units or subcontractors.

We have now extended this functionality with a built-in automation. You can now link certain organizations to specific service areas.

When organizations are assigned to the corresponding service area, we will now automatically set all related organizations as managing organizations when creating an empty tour or creating a tour by dispatching booking stops via these endpoints:

Consistent with our previously existing behaviour about managing organization inheritance, operations like dispatching booking stops into an existing tour do not further modify the managing organizations.

Support for managing this is also coming soon to our admin dashboard.

We want to make our platform even more adaptable to the specific needs of your business and use case, and therefore are introducing sophisticated new possibilities for configuring the way tours are shown to drivers.

In addition to already existing features like configuring the sorting order and algorithm of the pickable tours list and more, among the new configurable features you can:

• Configure how tour stops are being displayed in overview maps of lists
• Decide whether you only want to show the details of the first or first and last stop in lists

We are also introducing highly configurable labels, on both tours and stops. This allows you to choose and configure which details should be shown, and in what order, including:

• The distance to the first stop from the driver’s location
• The total tour distance
• Any metadata on the tour or any of it’s stops
• Driver Earnings
• Expected arrival time windows

You can freely add and remove these options and configure localized prefix and suffix values. For this, please use the new tour display admin APIs:

Additional driver experience related configuration options remain available via:

Support for configuring these interactively is coming soon to our admin dashboard as well, and our driver apps will receive updates in the next weeks that fully utilize these new configuration options for tour display.

Most notably, this gives you the ability to filter places based on their service area(s). Please note that service area coordinates can overlap, and hence a single place can be inside multiple service areas.

If your use case revolves around tasks at repeating customer locations, for example picking up goods at shops or meals at restaurants, it can be useful for drivers to be aware of where these locations are around them.

For this, we have introduced a new show_customer_places flag on our driver experience configuration API, which defaults to false. When enabled, drivers will be able to see the locations and names of the up to 100 non-archived customer places closest to their current location and inside their service area while online.

Support for configuring this is also available in the admin dashboard and the driver apps will soon start fetching and displaying these.

The endpoint supports the common filters also avaible on the regular package listing endpoint.

Support for creating these exports is also coming soon to our web dashboard for customers and admins.

If you’re using our booking pricing module on your tenant in certain scenarios you could have a difference in the overage distance calculated for the price and the booking distance shown in the web dashboard. The reason for this was that different sources where used for these before - now, this uses the same source for both.

Which source is being used depends on the route accuracy plan that you have purchased with us, either being straight line calculation or an actual maps-based route calculation.

Depending on your onboarding process for new drivers it can be helpful to restrict further editing of a driver’s profile details after initial onboarding. To facilitate this we have introduced a new option to restrict self-serving updates to a driver’s profile details after a successful initial onboarding.

This option is available to you upon request by reaching out to our customer success team.

Regardless of this setting admins and organization managers remain able to update a driver’s profile details using our web dashboard and the corresponding API endpoint.

When a driver is going online in the driver app we ask them about their current capabilities, which are subsequently used for selecting suitable tours.

Depending on your onboarding flow it can be necessary to do additional verifications like driver license checks during onboarding. In such situations it can be desirable to restrict the drivers ability to choose different capabilities after the initial onboarding. For this, we have extended our product with a corresponding optional configuration, allowing to restrict such updates so for example an onboarded driver always has a bike capability and cannot switch to a car without reaching out to your internal support team.

This option is available to you upon request by reaching out to our customer success team. It’s configurable whether drivers and/or org_managers can update these each, and the default remains as before that all of admins, org_managers and drivers can manage them.

Our driver apps will accordingly adapt to this setting and not offer the ability to choose corresponding capabilities that affect matching when going online.

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.

What’s new

Previously, our platform used a single, global vehicle type profile per tenant for all route calculations, regardless of the actual vehicle being used. This meant that whether your driver was using a bike, car, or truck, the system would calculate routes and estimates using the same parameters.

Now, you can configure unique vehicle type profiles for each vehicle capability value, enabling more accurate and realistic route planning that reflects the true capabilities and constraints of different vehicle types.

Why This Matters

Different vehicles have vastly different operational characteristics:

• Bikes can take shortcuts through parks and bike lanes but move slower on longer routes
• Cars balance speed and accessibility across most road types
• Trucks can require specific routes that accommodate size and weight restrictions

With vehicle-specific profiles, your route estimates and statistics will now accurately reflect these differences, leading to:

• More realistic delivery time estimates
• Improved customer expectations and satisfaction

How It Works

Configure Vehicle-Specific Profiles

You can now assign distinct vehicle type profiles to each vehicle capability value through our admin APIs:

Automatic Profile Assignment

When drivers go online in the driver app and select a vehicle capability the system automatically assigns the corresponding vehicle type profile to their account. This ensures that all subsequent tour calculations use the appropriate profile for their specific vehicle and means that estimated distances and times of arrival can change once a driver starts a tour if their vehicle type profile differs from the one requested on the tour.

Enhanced Route Calculations

The improved system now uses vehicle-specific profiles for:

• Arrival time estimates
• Tour statistics

Getting Started

If you’re already using our capability system with vehicle types, these improvements are automatically available. Simply configure vehicle type profiles for your existing vehicle capability values to start seeing more accurate route calculations.

For new implementations, the vehicle_type capability we create by default for new tenants will serve as your starting point for vehicle-specific configuration, and already comes with pre-configured vehicle_type_profile defaults.

Need help setting up vehicle type profiles for your fleet? Contact our support team or check out our API documentation for detailed implementation guidance.

Since the configuration of required proofs of delivery on tours is configured per tour service it cannot apply to off-tour package delivery & collection - therefore, a new dedicated configuration for off-tour package delivery proofs has been added to our packages configuration admin API. The available options depend on your plan at MotionTools, and specifically the purchase of the granular proofs configuration extension.

When marking a package as collected or force delivered the corresponding proofs will be collected based on this configuration in a similar way it would when delivering packages the regular way via a tour.

In addition to the API this functionality is also configurable from our booking service management in the admin dashboard.

When a package fails to be picked up or dropped of at a corresponding stop we move it into the failed status.

So far we only allowed to recover packages to one of your tenant hub places. To make resolving situations where the actual pickup of the package at its origin fails (i.e. because it wasn’t ready in time) easier we now additionally allow recovering packages to their pickup place. This makes it easier to re-attempt pickup of a package without having to do a cancel & recreate cycle.

This functionality is also available from our package management tools in the admin dashboard.

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.

This functionality was already available before in our web dashboard and via our API, but on the API it required taking a few individual calls to reach the desired state - you had to first undispatch the corresponding stops from a tour before you could move on to cancelling the booking.

With the new change the cancel transition will also appear for partially_dispatched bookings in their available_transitions via the API, and can then be cancelled using our generic booking transition endpoint.

Our package failure reason configuration already enables you to define specific failure reasons for your package pickups and deliveries in a self-serving way via the API as well as our admin dashboard.

We have now introduced an optional triggers_reattempt flag on failure reasons. When this flag is set and a package delivery is marked as failed in the driver app using a corresponding failure reason with this flag we will automatically append another delivery attempt stop at the end of the current tour. The driver can then move the stop into a reasonable position in the order using our familiar stop reordering feature in the driver app.

This new feature is intended to help in situations where upon delivery the driver becomes aware that a recipient might be able to be reached for delivery at a later point during the tour.

This can be helpful for integrating our packages with external systems as you can now more easily close the loop between passing the external_labels upon package creation and then listening for corresponding updates without having to store our own package ID or looking it up via API for identification.

This optional extension works by looking up the next closest available driver and marking them as preferred, instead of the default behaviour of pickable tours becoming immediately visible to all suitable drivers. It can help you in optimize the approach time on your tours by ensuring the closest drivers see and ideally pick tours, avoiding longer approach distances and thus driving times.

This feature is available as a paid extension via our customer success team - please reach out to us in case you are interested.

Once enabled you can configure this feature per operations configuration, so you can either have one central configuration for all of your service areas or go as detailed as having one individual per service area.

You can configure whether:

• driver_ranking is enabled
• gradual_rollout is enabled
• How long we should wait before rolling out to the next available driver via gradual_rollout_frequency_seconds

We also introduced an endpoint that allows inspecting the current ranking for drivers for a given tour:

Once the extension is enabled you can also configure it interactively through our admin dashboard.

If you offer self-pickup of packages at one of your hubs you can now facilitate this process through our packages product.

You can initiate the flow on packages that are at_hub or scheduled_for_delivery by triggering the corresponding request_collection transition:

An eligible package can then be marked as collected using the corresponding endpoint:

Our driver apps were updated accordingly, allowing to utilize this new feature from the package scanner.

This makes it easier to interpret whether a certain event listed is for example a pickup at the origin or at a hub.

• When a package is scheduled_for_delivery or out_for_delivery we will now include the latest estimated time of arrival for the package dropoff stop at the destination
• We will provide the driver’s approximate current location when they are approaching the package destination dropoff stop and the package is therefore out_for_delivery
• For packages that are out_for_delivery we will also provide the approximate number of stops for them to reach the package’s destination stop on the tour

Our public package tracking page was adjusted accordingly to reflect this additional information.

When chosen we provide the following variables for the custom algorithm:

• scheduled_in_seconds - How many seconds from now the tour is scheduled
• driver_distance_meters - How far away the viewing driver is from the first stop location
• tour_distance_meters - How long the estimated tour is in meters

Using these variables in the custom sorting algorithm can help optimize your operational efficiency significantly by increasing the likeliness drivers that pick a tour are close to the first stop, prioritize longer tours or those that are late, or any combination of these, depending on your operational requirements and optimization targets.

This feature is available as a paid extension via our customer success team - please reach out to us in case you are interested.

The configuration of the custom sorting algorithm itself can only be changed via our customer success team at this time upon your request, however once enabled you can switch it’s usage off and on using the corresponding driver experience admin API or in our web dashboard.

We are tracking arrived_at, completed_at, and failed_at timestamps on stops, as well as keeping a separate events history. So far, there could be discrepancies between the individual timestamps of these events between the events history and the dedicated timestamps - we have adjusted our stop completion logic to keep those aligned so the timestamps will always match.

We have also made adjustments to the completion of grouped stops, where we now ensure the corresponding grouped stops will also have the same timestamps throughout, matching those on the initial completed grouped stop.

Additionally our driver apps now handle clock skew in a better way - if the clock on the device of a driver is incorrect, so far the resulting stop timestamps could be wrong from the actual time the corresponding arrival or completion events occured, both in offline as well as online stop completion. We will now adjust those timestamps according to the real time based on the delta of the driver’s device clock to the actual time.

You can find the flag in permissions.removable on the package response payload, making it easier to figure out whether the operation to remove a package can be succesfully called.

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.

Before, such packages were being moved back into at_hub status the tour was originating from but this behaviour didn’t make sense in case of the force-ending of a tour as it is meant for completing the tour without the driver’s interaction.

The feature relies solely on the phone number attached to the currently active stop of a tour, which can be set either on booking or individual stop creation or by updating the stop contact details via the dedicated API endpoint or from our web dashboard.

When a driver chooses to call the stored stop phone number and the feature is enabled they will instead call a dedicated phone number specific to your tenant, and we will proxy the call to the final destination defined on the stop. The customer will see the call coming in from your tenant-wide phone number, and once connected the driver and customer are able to discuss delivery details via phone without revealing each other’s real phone numbers.

We have also included additional phone number sanitization and normalization rules which fix many common errors in the phone numbers provided by users, increasing successful phone connection percentages, and therefore speed to reach the stop, significantly.

These features are available as a paid extension via our customer success team - please reach out to us in case you are interested.

So far, you were only able to either retrieve tenant-wide places or places for specific customer IDs. We have now introduced additional options to this filter:

• customers_only - will list only customer places, but for any customer
• include_customers - will list tenant-wide places alongside customer-specific places

Additionally, when making requests as an admin we will now show some details about the customer user account for customer places in the corresponding API responses.

Our web dashboard has been adjusted accordingly to support these new options.

To facilitate this we have introduced a new driver experience API. The new API allows you to adjust the following behaviour in our driver app:

• The field to sort pickable tours by - either by scheduled_at or by the distance from the driver’s location
• The sorting direction of the pickable tours list
• The maximum number of results to show in the pickable tours list
• The maximum distance a driver can have from their current location to the first stop of a tour in the pickable list

You can use these new features to optimize the way tours are shown to drivers in a way best suitable to your business model, operations and driver availability.

A corresponding UI based configuration is also available in our admin dashboard.

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

So far admins already had the ability to set an optional maximum_driver_distance_meters on stops when creating bookings, inserting custom stops into bookings or tours, or by updating them. When set a driver is prohibited to mark a stop as arrived when outside of the specified aerial distance from the stop location.

We have extended these functionalities with additional features:

Automatic arrival at stop

In addition to the maximum_driver_distance_meters we now also allow defining an auto_arrival_distance_meters on the same endpoints. When set the driver app will automatically mark the stop as arrived when the driver enters the given radius from the stop location.

Defaults from booking and tour services

Additionally to the manual passing or setting of these values via the API we now also allow defining defaults for both maximum_driver_distance_meters as well as auto_arrival_distance_meters on the booking and tour services for each stop type.

When configured stops where the corresponding service applies will automatically be created with these defaults applied.

When provided booking receipt e-mails sent by our platform will instead be delivered to this dedicated address instead of the user’s default account e-mail.

The corresponding endpoints allow for providing additional information to drivers, changing the tour name as well as attaching order images and documents. Especially the latter can be particularily helpful when additional order documentation is prepared after completion and hence can now be easily attached to the corresponding stop, booking or tour.

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.