/delivery (relative to your instance’s /api/v2).
The standard endpoints provide reads and writes, subject to the constraints below.
Search columns: name, identifier, poNumber
Fields
Choose the creation workflow
POST /delivery creates an inbound header. For outbound or transfer trips use POST /delivery/outbound, which creates the paired deliverable group and public token. It accepts name, optional direction (outbound or transfer), itemIds (cargo deliverable IDs), workerIds, truck/contact references, source/destination fields, and planned start/end times. A planned end must be after the planned start. Component cargo additionally requires deliveryComponentCargoEnabled; the service validates cargo eligibility.
Generic inbound creation uses expected; direction cannot be changed later.
Inbound statuses are expected, in_transit, received, and cancelled.
Outbound/transfer statuses are scheduled, in_transit, delivered, and
cancelled. Move between them with the lifecycle actions below, not generic
PATCH. Partial completion is derived from cargo quantities/progress; partial
is not a stored status.
Receiving and lifecycle
POST /delivery/{id}/start, /complete, or /cancel for outbound lifecycle transitions so cargo and the paired group stay synchronized.
Use POST /delivery/{id}/archive and /restore for archival. Both require
delivery delete permission, and only a received, delivered, or cancelled trip
can be archived. Generic PATCH rejects isArchived and archivedAt.
plannedStartAt and plannedEndAt are paired-group schedule projections; edit
them through PATCH /delivery/{id}/outbound. publicToken,
deliverableGroupId, truckName, cargo counts, and isLate are read-only.
Read a trip’s stops and legs with GET /delivery/{id}/itinerary, and cargo spans with GET /delivery/{id}/cargo-plan. Manifest lines are a separate resource.