Three loading docks. Two forklifts. Eleven people on the early shift. Whatever the optimiser decides, that building can move a certain amount of goods in a day and not one pallet more.
Load limits in planning have traditionally been asked at one place only: what fits on the vehicle. It is a fair question and the model has always answered it. But a plan touches load in more than one place, and two of them were outside the picture — the throughput of the site the goods pass through, and the total amount a single person handles over a shift.
At the building: inbound and outbound ceilings
Depots now carry their own load constraints, in a maximumLoads object under the depot’s constraints. It holds two lists: inbound for what is delivered to the site, outbound for what is picked up from it. An entry is the same small load object used everywhere else in the API — a dimension and a value — so you can limit several dimensions on the same depot at once. The dimension names are yours and are the ones your orders already use, so the units are whatever those dimensions mean: kilograms for weight, cubic metres for volume, pieces for a count.
Two properties of these limits shape how you use them. They are per optimisation run rather than per vehicle or per visit, so they describe the throughput of a planning period — typically a day. And the two directions are fully independent: set one, the other, or both. That independence matters because sites are rarely symmetric. A distribution centre may dispatch 50,000 kg comfortably while its receiving bay, staffed and equipped differently, tops out much lower. Modelling only the tighter figure used to cost dispatch capacity; modelling neither produced plans that arrived at a site the site could not absorb.
Where goods types differ, the lever is the dimension. A maximumLoads entry is a dimension and a value, with no order-category filter on it, so the way to give frozen goods their own ceiling is to give them their own dimension. That is the right model anyway: frozen goods do not compete with ambient goods for the same handling capacity, they compete for freezer space — a different and much smaller resource. Declare it as a dimension and it gets an inbound limit independent of the general one.
Category filtering does exist at a depot, but on the cost side rather than the constraint side. Depot load costs price load per batch — a batchSize, a costPerBatch — and take an orderCategory filter. So the two instruments divide cleanly. Use a dimension limit when a volume is genuinely impossible; use a category-filtered cost when you want to discourage a class of goods through a site without ruling it out, and let the optimiser decide when paying for it is the better plan.
At the person: the total a shift adds up to
At the other end of the chain sits maximumTransportedLoads, on the vehicle under its route constraints: a limit on the cumulative load a single route handles, counted across everything picked up and delivered on that route. Like the depot limits it is written per dimension, so weight and volume can be capped independently. What it sums is the load of all orders the route executes — once per order, whatever number of handling operations that order involves — which is worth knowing before you fix a value on pickup-and-delivery work.
This is a separate question from vehicle capacity, and the difference is easy to miss because both are measured in the same units. Vehicle capacity asks what may be aboard at one time. The cumulative figure asks what passed through the driver’s hands over the whole shift — a total that grows with every reload cycle and every subtour, while the capacity figure never changes. Where handling is manual, this total is what health and safety policy is written against, and it can now be capped in the plan rather than reviewed after it.
The two limits doing different jobs
It helps to see where each one binds.
A depot limit shapes allocation. It decides how much work leaves this site versus another, which orders get served from where, and how demand distributes across a network on a busy day. It is a network-level answer.
A route limit shapes composition. It decides how much work goes onto one shift and, in effect, whether a fifth reload cycle happens at all. It is a shift-level answer.
Both are ceilings on load, and they interact in the way you would expect — a depot near its outbound limit sends fewer heavy routes; a fleet near its handling limits draws less from each depot. Neither substitutes for the other, and neither substitutes for vehicle capacity, which continues to govern the moment.
What this replaces
The workarounds for depot throughput were all approximations of the same kind: pretend the constraint is something else. Restrict the vehicles assigned to a site, so less can leave it. Cap the number of orders, so volume is implied by count. Split the day into artificial periods. Each one buys throughput control by giving up accuracy somewhere else — vehicles that could have been used elsewhere, or an order count that treats a 40 kg parcel and a 900 kg pallet as equivalent.
Stating the throughput limit directly gives the optimiser the real shape of the constraint, and leaves the vehicles and the order list to describe what they actually describe.
For teams building on it
Both constraints are additive and sit where you would look for them — depot limits under the depot’s constraints, cumulative load under the vehicle’s route constraints. For anyone integrating PTV Developer into a TMS or warehouse-facing product, the more interesting point is that depot throughput is data those systems already hold. Dock counts, shift rosters, cold-storage volumes and receiving capacity live in the warehouse system, and until now there was no field in the plan that corresponded to them. Now there is, which means a site’s real capacity can flow into planning automatically instead of being represented by a planner’s rule of thumb.
The result worth aiming at is fewer plans that look feasible on the road and fail at the gate. A truck waiting for a dock is a cost that never appears in a route optimisation report, and it is paid in driver hours.
The tighter half of the operation
Warehouse capacity has become the tighter half of most distribution operations. Labour is harder to recruit, volumes are peakier as order patterns fragment, and cold and controlled storage is expensive enough that nobody builds slack into it. Meanwhile the physical demands on drivers are under real scrutiny, in policy and in law.
Planning that only asks what fits on the truck is answering the easiest of the three questions. All three now belong in the same request.
