Changelog

A cancel that arrives after the order is loaded can now bring the order back to the store instead of being refused. Returns are enabled per site; ask your Autolane contact to switch them on.

What changed

• PATCH /dd/v1/deliveries/{external_delivery_id} with status: CANCELLED at LOADED, EN_ROUTE_TO_CUSTOMER, or ARRIVED_AT_CUSTOMER answers 200 with status: RETURN_IN_PROGRESS on sites with returns enabled, unless the trunk has already opened at the customer’s door, in which case the handoff wins instead. Sites without returns still get 409. The body accepts an optional cancellation_reason; any value is accepted, and an unrecognized or non-string value is recorded as OTHER.
• Three new statuses, RETURN_IN_PROGRESS, RETURN_ARRIVED, RETURNED, on pickup_status.changed and on GET. They always arrive in that order and RETURNED is terminal. After RETURN_IN_PROGRESS a delivery never reports EN_ROUTE_TO_CUSTOMER, ARRIVED_AT_CUSTOMER, or COMPLETED.
• New fields on the return statuses: return_reason, return_stall_id (sites with stall reporting), and return_fee_cents on RETURNED. estimated_arrival on RETURN_IN_PROGRESS is the arrival back at the store.
• 409 DELIVERY_ALREADY_COMPLETED when a cancel lands after the handoff to the customer, or once the trunk has opened at the customer’s door.
• A repeat cancel during or after a return answers 200 with the current status and sends no new webhook.
• Sandbox. The portal’s Advance button steps a returning delivery through RETURN_ARRIVED (with an optional Return stall ID) and RETURNED.

Migration

No action is required unless you want returns. Integrations that reject a status they do not know should add the three return statuses. Integrations that de-duplicate webhook events on (external_delivery_id, status) should exempt events whose previous_status equals status, as for stall corrections.