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.

We have started the rollout of new Android and iOS driver app releases that bring significant improvements to the active tour functionality — the screens a driver works from in the driver app³ between starting a tour and completing its last stop. While this does not come with direct public APIs to use, we still want to highlight the improvements here, how they build on top of previously announced features, and what they improve for your drivers and your operations.

You can now stop a driver from going online without blocking their account. A restricted driver stays signed in and can still reach support and look at their past tours — they simply cannot go online until the restriction is lifted. Every restriction carries a reason, names the person who applied it, and is written into the driver’s notes.

Route optimization can now be submitted instead of waited on: Submit a route optimization⁶ takes the problem and answers straight away with a job ID, and Fetch a route optimization⁷ returns the finished route once it is ready.

We have introduced notes — free text you can attach to your data, stored together with the author, the time and where the note was written. A note cannot be edited or deleted once written.

Grouped stops let a driver handle several stops as one at the roadside: completing the first stop of a group completes its grouped siblings with it. Two refinements to the grouping rules now make that behaviour both safer and more flexible — a group only takes effect when its stops are genuinely at the same destination, and differing custom content no longer splits a group.

We’ve introduced a generic reports API — one reliable place to publish a generated file and deliver it to exactly the people who should see it. Create a report, choose its audience, and each recipient can list, open and download it through the same API, with files kept encrypted at rest and cleaned up automatically when they expire.

When several organizations work the same service areas — fleet partners, 3PL sub-fleets, or a mix of your own and external drivers — their managers should see the work that concerns them, and nothing that doesn’t. The platform now takes care of that automatically: from the moment a driver picks, claims, or is force-assigned a tour, the tour and its bookings are visible only to the driver’s own organization, which is also the only organization receiving their live updates and notifications. No information leaks between competing organizations while the work is on the road.

Failing a stop now answers the question that matters most in the field: what happens next? The fail endpoint accepts a recovery outcome that turns a failed delivery into an explicit, auditable next step — send the goods back, try again, or accept the failure — without juggling manual stop edits or custom integrations.

Stops created from a place are now grouped automatically. When several such stops end up on the same tour — the classic stacked-tour case of two orders picked up at the same location — they are recognised as one group and completed together, with no manual grouping step and no custom integration to maintain.

Failed booking stops are now terminal: once a stop is failed, it can no longer be dispatched again into a tour. A stop’s outcome is now final and auditable — a failed stop stays failed, and recovery happens by adding a new stop to the booking rather than by reviving the original one.

The permissions endpoint (GET /api/user/permissions) now reports a top-level places flag, giving you a single, role-accurate signal for whether the current user can work with places.

Our tenants can now share how busy their workforce is, place by place, with their customers — who can then react automatically, throttling demand or temporarily offlining a merchant when deliveries can no longer keep up and re-opening it as the workforce catches up.

Tips set on individual bookings now flow automatically onto the tour compensation object when a tour completes — so everything a driver earned (base earnings, bonuses, and tips) lives in one place instead of being stitched together after the fact.

When a booking carries a tip, the tip.currency value is now required to match the booking’s applicable currency — the service area’s local_currency, falling back to the tenant’s base_currency. Tip writes in any other currency are rejected with a 422 and the new booking_tip_currency_mismatch operation failure code.

The driver tour display configuration covers two distinct screens — the off-route view a driver sees while browsing tours, and the active-tour view they see while working a tour. Operators typically tune these screens independently: changing only the active-tour earnings label, or only the off-route metadata layout, without wanting to revisit the rest of the configuration.

We have introduced a structured tour compensation object as the single source of truth for what a driver is paid out for a tour. It consolidates base earnings, bonuses, and tips into one auto-totalled view — exposed via a dedicated API, surfaced to drivers on tour cards via two new configurable labels, and observable for server-to-server integrations through a dedicated webhook.

We have introduced a unified reasons API that serves configurable failure reasons across the platform in a single, consistent format. Two categories are live today — stop failure reasons and package failure reasons.

We have introduced return as a new stop type, enabling return-flow booking patterns where items are brought back to a designated location after delivery. This extends the existing stop types (pickup, dropoff, task) with a fourth option that can be used on bookings and tours.

Following the configurable off-route tour display²⁴ we introduced last year, we are now extending the same configurability to the active tour screen — the view drivers see while they are actively working on a tour. The configuration is available now via the admin API, and our mobile apps will receive updates in the upcoming weeks to fully utilize these new options.

All booking and tour creation endpoints now accept an optional service_key parameter as a more stable, human-readable alternative to service_id for selecting a hailing service.

We have introduced a new verification content type for stops that enables client-side verification workflows, such as verifying a recipient’s date of birth or entering a PIN code.

As part of the ongoing transition from booking to tour terminology, the following changes have been made:

Organization managers with multiple managed organizations can now specify which organization to invite drivers to by providing the organization_id parameter in the invitation request.

We have enhanced the booking.in_progress webhook to fire not only when a tour initially transitions to en_route, but also when bookings are dispatched into a tour that is already in progress via the DispatchStopsIntoExistingTour endpoint.

An adjustment has been made to the User Invites endpoint’s validation error response: when an invitation that specifies components for the SSO setup (external_id and auth_provider_key) fails, the returned error messages for the index for which they failed won’t be wrapped in the array anymore:

In an effort to further minimize the minimal tour/booking view, we have introduced dedicated endpoints for fetching preferred drivers and related flags for tours/bookings.

We have simplified the rules regarding visibility of bookings and tours for the org_manager role and completely base it off the managing organizations that are set on the bookings/tours from now on.

We have extended our existing booking and tour webhook notifications to always include the related service_area_id as well.

We have introduced new booking lifecycle webhooks to gain more transparency into their execution via the tours.

We have introduced an optional external_id attribute on places. This gives you additional capabilities in synchronizing another, leading system with the booking and places data in MotionTools.

We have introduced support for passing external IDs on the booking creation that will be stored in our system and becomes visible in API responses and booking-related webhook notifications.

We have introduced a dedicated webhook for notifying about tour earnings update.

We have introduced configurable cancellation policies for booking services. The new policies allow you to configure until which point customers can cancel their bookings per booking service:

We have introduced the ability to add additional instructions for the driver as custom content on stops using pre-defined templates as admin and regular customer, both on booking creation and when inserting a custom stop into a booking or a tour.

We now also allow admins to cancel bookings that are fully dispatched more easily - meaning all their stops are dispatched into one or more tours.

We now allow updating the requested_capabilities on bookings and tours.

We have introduced the ability to declare an optional tip amount and currency to send to a driver upon booking creation.

We have introduced the ability to assign drivers to specific service areas.

We have introduced the ability to link organizations and service areas to each other, allowing to automate visibility of tours.

Customers can now also request a CSV export of their bookings.

We have introduced the optional ability to display nearby customer places in the driver app’s map.

We will now create links between service areas and places based on their location.

We are reworking the way pickable, scheduled, claimed, completed and cancelled tours are being displayed in our driver apps.

We have introduced the ability to export package information in a CSV file.

Our user search will now also consider the company name listed on customer profiles, if present.

We will now use the same source for calculating the distance of a booking for statistics as well as for calculating the price from the price matrix.

We have introduced the ability to restrict updates to driver profiles.

We have introduced a managed mode for driver’s capabilities, where admins and optionally organization managers and drivers themselves can update them.

We’re excited to announce significant improvements to our vehicle type profile system, giving you more granular control over route calculations and estimates based on your actual fleet composition.

We now allow configuring and collecting proofs of delivery for packages that are force-delivered or marked as collected.

We now allow recovering a failed package to its original pickup place.

You can now define optional, localized pricing_details_url_translations on booking services which will be used to show localized links for further pricing information in your web booking portal for customers.

We have made it easier for admins to cancel partially dispatched bookings in a single API call.

We have introduced the ability to append delivery reattempts for failed package deliveries on the same tour via a corresponding failure reason.

Our package transition webhook notification now also contains the external labels of the package

We have introduced an extension giving you the ability to roll out pickable tours gradually to available drivers based on their distance from the first stop.

We now allow updating the list of preferred drivers on tours that are already en route.

We now include the location_type on package interaction based properties on the package journey.

We have introduced a new package flow for picking them up from a hub, skipping delivery via a tour.

We have extended the information available on the public package tracking API.

We have introduced an extension for providing a custom sorting algorithm to determine the order pickable tours appear in on the driver app.

We now indicate the permission to remove a package from a tour on the package payload.

We have made adjustments to unify the stop arrival, completion and failure timestamps, as well as the events history. We have also adjusted our apps to compensate client-side clock skew.

When force-ending a tour a package is currently on in the status scheduled_for_delivery we will now mark this package as delivered.

We have introduced the masked communication extension, which allows drivers to call customers without revealing the real customer or driver phone number to either party.

We have introduced the ability to request customer and admin / tenant places together in the places list.

We are extending the self-serving configurability of the driver experience in our apps.

We have loosened the restrictions for updating the additional information of bookings, tours and stops and now also allow updates even after they are completed.

We have introduced a new, optional billing_email field on our invoice address account feature.

We have extended our geofencing capabilities around the arrival at stops.