Pickup & delivery transfersCopy link
Depot orders assume goods start or end at your warehouse. Courier work is different: pick up flowers at the florist, deliver them across town, never touching a depot. In Routing24 that is a transfer: two orders linked into one pickup-and-delivery pair. Transfers are a Pro feature. The free tier can use them within the free paid-feature optimizations.
This tutorial plan mixes three transfers with four regular depot orders:
How a pair is modeledCopy link
A transfer is two orders sharing a Transfer id:
- The pickup end: Order type = Transfer order (PUD), role pickup, with the consignment in its Pickup field.
- The delivery end: same Transfer id, role delivery, the same quantity in its Delivery field.
The loads must match. Each end keeps its own address, time window, and service duration, so "pick up after 10:00, deliver before 14:00" is two windows, one per end. Priority, tags, and Load class belong to the consignment and must be the same on both ends.

In the editor, choosing Transfer order (PUD) reveals the Transfer id
field with suggestions from existing half-pairs, and warns while a pair is
incomplete. In spreadsheets, the Order type and Transfer id columns do
the same (see the
column reference).
Either end may also offer several candidate addresses, for example the home address OR a locker. See alternative locations.
What the solver guaranteesCopy link
For every pair, always:
- One vehicle serves both ends. No handoffs between vehicles.
- The pickup comes before the delivery.
- The consignment occupies capacity between the two stops, alongside whatever depot loads the vehicle carries.
- A pair may span a reload: the delivery may land in a later trip than the pickup. At the mid-route depot visit the vehicle swaps its depot loads while the consignment rides through, still on board and still counting toward capacity until it is delivered.

Route cards draw the link under each transfer stop, naming its partner.
Limiting the ride timeCopy link
A pair can cap how long the consignment stays on board: Max time in vehicle, in minutes, on the transfer's ends. It bounds the ride from the end of service at the pickup to the start of service at the delivery. The planner delays the pickup service where that shortens the ride — the consignment stays at its origin instead of boarding early — so only waiting that no feasible loading time can avoid counts toward the bound, and a reload in between does not reset the clock. Flowers collected at 09:00 under a 45-minute bound are at the recipient by 09:45, whatever the route does in between.
This tutorial plan bounds a gelato transfer at 30 minutes while the receiving hotel opens at 10:00, so the planner holds the goods at the pickup and boards them late:
Set the same value on every end of the transfer, each candidate address included when an end offers alternative locations: the clock may not depend on which candidate wins. Ends that disagree are flagged as non-blocking warnings on import, and the whole transfer is skipped at optimization so the rest of the plan still solves.
Max ride overtime adds a priced band past that bound, also in minutes. Ride time inside the band is allowed and charged at the vehicle's Ride overtime cost per hour; beyond the band the bound is hard. It requires Max time in vehicle on the same transfer. See Vehicle costs and the COST metric.
Both fields sit in the order editor under Release time, next to the plain-order form of the same field, and are described in Max time in vehicle (shelf life).
Max time in vehicle combines with driver breaks. Break placement avoids the span between a pickup and its delivery where it can; a break placed inside the span counts toward the ride like driving or waiting does, is charged against Max ride overtime where one is set, and past that band the bound stays hard, so a transfer that cannot meet its bound around the mandated breaks goes unassigned with the "Max time in vehicle" reason. See Driver breaks and driving-time limits.
When a pair cannot be placedCopy link
If either end does not fit, both go unassigned, with a reason naming the pair ("must be served on the same route as its linked delivery, before it"). The same applies when you edit by hand: drags that would split a pair across vehicles or invert the order are validated by the engine like any other change, and insertion suggestions may place the delivery in a later trip than its pickup, since the goods ride through the reload in between.
Mixing with depot workCopy link
Transfers and depot orders coexist on one route. A courier can leave the hub with depot deliveries, weave three transfers through them, and return with pickups, as the tutorial plan shows. The optimizer applies the pair constraint while minimizing cost.
Next stepCopy link
Next: Run the optimizer.