Cap a route at nine hours and you have said something about the shift. You have said almost nothing about the driving.
Those nine hours contain loading at the depot, service time at each customer, waiting for a time window to open, and the driver’s breaks. The actual time at the wheel might be four hours, or it might be seven. Driving-time regulations care about the seven. A route-duration cap cannot tell them apart, which is why a plan can sit comfortably inside its shift limit and still put a driver over the daily driving allowance.
Route constraints in the Route Optimization OptiFlow API now separate the three things that a single shift can run out of: time at the wheel, stops served, and weight handled.
A cap that counts only the wheel
The first is a maximum driving duration, and its definition is the whole value: it counts pure driving and nothing else. Breaks are excluded. Service time is excluded. Waiting at a closed customer is excluded.
That makes it the constraint that maps directly onto fatigue rules, which is where planners have needed it. A limit of four and a half hours of continuous driving is a regulatory number, not a shift number, and it can now be stated as such. Set it and every plan respects it, regardless of how much standing around the day happens to contain.
The practical difference shows up in long-distance work with heavy waiting. Under a route-duration cap, an hour spent waiting for a dock slot consumed the same budget as an hour of motorway driving, so plans came back conservative — the optimiser protecting a limit that the waiting hour was never really threatening. Separate the two and that hour stops eating into driving allowance it was never spending.
A cap that counts the doors
The second is a hard limit on the number of stops per route. It is the least sophisticated of the three and often the first one asked for.
The reasoning is rarely about capacity. A route with 40 stops may fit the vehicle and the shift perfectly well and still be the wrong route: the driver is rushed, the last customers get a worse experience than the first, and the plan has no slack for the one delivery that goes wrong. Capping at 25 stops is a service-quality decision and a fatigue decision, and it is easier to defend as a number than as a hoped-for outcome of the cost model.
Before this constraint, planners approximated it — inflating service times, tightening shift durations, splitting territories. Each of those distorts something else in the plan. A stop count is a stop count.
A cap that counts the kilos, all day
The third cap is the least familiar and the one most worth sitting with, because it measures something vehicle capacity has never captured.
A vehicle that carries 10,000 kg is a statement about a moment: how much can be aboard at once. It says nothing about the day. A driver who runs five full reload cycles has physically handled 50,000 kg. A driver who runs two has handled 20,000. Same truck, same capacity, very different shift — and until now the plan could not tell them apart, because instantaneous capacity was the only load figure in the model.
Maximum transported loads caps the total load of all the orders a route executes, however many subtours or reloads it takes to execute them. Where the work is heavy and manual, that total is the number that correlates with strain and injury, and health and safety policies are increasingly written against it. A ceiling of 50,000 kg per shift is now something the optimiser enforces rather than something a supervisor checks afterwards.
The fields, and one name that means two things
All three sit on the vehicle, under constraints.route, next to the duration and distance caps that were already there.
| Field | Type | Counts |
|---|---|---|
maximumDuration |
seconds | everything: driving, service, preparation, waiting, breaks, charging |
maximumDistance |
metres | route distance |
maximumDrivingDuration |
seconds | driving only |
maximumNumberOfStops |
integer | stops on the route |
maximumTransportedLoads |
list of per-dimension limits | total load transported over the route |
Two details in that table repay attention.
The first is that maximumDrivingDuration appears twice in the API, in two different places, meaning two different things. Under constraints.route it caps the total driving on the route. Under the vehicle’s driving break settings it caps continuous driving — how long the driver may go before a break — and it resets each time a break is taken. Both are in seconds and both are legitimate; they answer “how much driving in the day” and “how much driving in one stretch”. Set the wrong one and the plan will be wrong in a way that looks like an optimiser bug.
The second is what counts as a stop. The documented rule is that each stop counts once regardless of how many orders are picked up or delivered there — so ten drops at one address are one stop, which matches how a driver experiences it: one arrival, one parking manoeuvre, one door. The limit is about locations visited, not work done, which is exactly why it is the right instrument for workload and complexity and the wrong one for volume.
If you want a soft limit rather than a hard one, the cost model has an alternative: overstop costs, which price each stop above a threshold. Several thresholds can be stacked, the extra costs apply cumulatively as each is passed, and a fixed surcharge can be added at the moment a threshold is reached. That lets the optimiser go past your target when the alternative is genuinely worse, instead of refusing.
Transported loads are expressed per dimension — the same dimension names you already use for order loads, such as weight or volume — each with its own maximum value. What it limits is the sum of the loads of all orders executed on the route, and the unit of counting is the order. An order counts once towards the total no matter how many handling operations it involves, so a pickup-and-delivery pair adds its load once, not twice.
That distinction is what to keep in mind when choosing a number. On a delivery-only route the total is the weight the driver takes off the vehicle, and the figure means what you expect. On pickup-and-delivery work the driver touches each consignment twice while the total counts it once, so a ceiling meant to reflect physical handling needs to be set lower than the weight you have in mind. Work out which pattern your routes follow before fixing the value.
Reading the three together
Set alongside the route duration and distance caps that already existed, the picture is a set of independent ceilings, each measuring a different resource the shift consumes. A route can be short in distance and heavy in handling. It can be long in hours and light on driving. It can be well inside every time limit and still have too many doors on it.
Because the caps are independent, the binding one tells you something. If plans consistently hit the stop limit, the constraint on the operation is service capacity. If they hit driving duration, it is geography. If they hit transported loads, it is the physical work. That is diagnostic information a single blended limit hides — and for teams building planning products on PTV Developer, it is the kind of thing worth surfacing back to the user.
Where it fits in a product
For integration partners embedding PTV Developer, these caps are additive and sit at the vehicle level, under route constraints. A profile per vehicle type — regional truck, urban van, heavy distribution unit — carries its own set of ceilings, and the optimiser holds all of them in one run across a mixed fleet. Nothing needs to be reconciled after the fact.
The context is that driver wellbeing has moved from good practice to policy, and in several markets to obligation. Working-time and driving-time enforcement is digital and auditable. Ergonomic limits appear in collective agreements. A plan that respects them by design is worth more than a plan that has to be corrected into compliance every morning.
