POST /api/v1/optimization/doormile/sequence. Same optimizer, same
riders, same kitchens, same step semantics as the provider flow -- it
only differs in the shape of the payload. Doormile keys on bookingid and
sends pickuplatitude; the provider flow keys on deliveryid and sends
pickuplat. Rather than making Doormile translate itself into jupiter's
vocabulary on the way in and back out, it gets an endpoint in its own
terms. The routing is not reimplemented: this maps onto the internal
shape, calls the same optimize_provider_payload, and maps back.
start_coords is passed through, so a run starts from the kitchen instead
of being inferred from whichever stop happens to be first.
/optimization/createdeliveries is deliberately untouched -- jupiter is
live on it and tightening its body would break real deliveries. But that
endpoint takes list[dict], so a payload with the wrong field names
returns HTTP 200 "Success" with every coordinate defaulted to 0.0, no
reordering and all distances zero. Nothing depends on the new endpoint
yet, so it validates strictly and rejects that outright. It also rejects
0,0 coordinates: inside the valid range, but a point in the Atlantic
that drags an entire route toward it.
Single stop short-circuits to step 1 rather than spending an OR-Tools
solve. Duplicate bookingids are refused, since results are keyed back by
bookingid and a duplicate makes the caller's mapping ambiguous. Steps for
bookings the caller never sent are dropped -- callers write these onto
their own rows.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
f804791864