What makes this vertical distinctive
- Key-holder-only access windows — a locker or secure site opens early only to drivers who hold the key, with a narrower standard window for everyone else.
- Blended subcontractor/in-house costs — subcontractors are paid a flat fee covering their first few drops plus a rate per extra stop delivered, in-house drivers a straight per-kilometre rate — one cost model, two structures.
- Pre-opening store drops — store deliveries land in an early window before the shop opens, for chains that need it.
- Trusted-keychain deliveries — a set of key-gated stops is kept to a single driver for the day.
Combined example
Early access for key holders
order-locker-site carries two authorizedTimeWindows: an early one (06:00-20:00) tagged resourceTags: ["key-holder"], and a narrower standard one (09:00-17:00) with no tag. Only driver-key-holder can use the early window; every other resource is restricted to the untagged one. See Restricting a window to specific resources.
Blended subcontractor/in-house costs
driver-key-holder.cost.km.costCoeff: 1.2 charges a straight per-kilometre rate. van-subcontractor-a.cost is instead priced per stop delivered, through costsByCapacity on a stopsDelivered capacity that every stop increments by 1: a flat constantCost: 80 that covers the first 3 stops (costFloor: 3), then costCoeff: 15 for each stop delivered beyond that. The two resources are priced on different structures, but both roll up into the same minimizeCosts objective for a single, comparable plan. See The cost object and Piecewise-linear cost functions.
Pre-opening store drops
order-store-1.authorizedTimeWindows is a single hard window (05:00-06:45), ahead of the store’s opening hours at 07:00 — an ordinary authorizedTimeWindows use, no different in kind from Multiple time windows per stop, just with one window instead of several. In the full payload below, van-subcontractor-a starts its day at 04:30, because a vehicle whose day starts when the window closes can only deliver at the last minute. The window ends at 06:45, not at the 07:00 opening, because a time window limits when the vehicle arrives, not when the unloading ends: its end is the opening time minus the 15-minute unloading.
Trusted-keychain deliveries
order-keychain-0 carries the tag keychain:trusted-set-1. A globalConstraints entry of type maxCumulatedCost gives every driver-tagged resource a cost on the stops of that set: costCoeff: 1 counts each keychain stop the resource visits, and overcostFloor: 1 with overcostCoeff: 0 stops the count after the first one. Each driver therefore costs 1 as soon as it takes a keychain stop, and maximum: 1 across the whole fleet leaves room for a single driver on the set. The constraint only counts resources that carry the tag it targets, and a wildcard isn’t accepted, so the subcontractor vans carry driver too: without it, they could take keychain stops freely. If no single driver can reach every stop of the set in time, the extra stops stay unplanned, in unaffectedStopIds, rather than going to a second driver (see Handling infeasibility). See Constraints catalog.
Full payload
Full payload — ready to submit as POST /plans
Full payload — ready to submit as POST /plans
The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (
workingTimeWindow, departure, arrival), the complete objectives list, and enough orders to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own. Its datetimes are local times, read in the plan’s tz (Europe/Paris); see Dates and time zones.See also
- Modeling advanced constraints —
resourceTagson a time window. - Cost modeling — the full
Costobject, includingkmandcostsByCapacity. - Data model — the full
additionalConstraintsandglobalConstraintscatalog.

