Skip to main content
Update an existing Shipment with POST /v5/shipment/update/, identifying it by the shipment_uuid or shipment_id query parameter:
The request body takes the same fields as Create Shipment; none are required. Full field specs: API reference.

​
Replace, append, or locked — know which is which

Most fields replace the stored value entirely. That includes three cases that surprise integrators:
  • line_items and shipping_costs replace the whole array. Sending one line item removes all others. To keep existing items, resend the complete set.
  • Each address object replaces as a unit. Sending to_address with only a new postal_code erases the rest of that address.
  • notification_email / notification_phone replace the whole array — to add a recipient, send the full list.
Four fields append instead: tags, events, linked_shipments, and documents. Values you send are added; nothing is removed. (v5.0 has no way to remove tags — that’s what the v5.2 endpoint below is for.) Locked fields:

​
Manage tags with v5.2

POST /v5-2-0/shipment/update/ adds tags_action, which controls how the tags you send are applied:
Sending tags_action without tags returns a 299 warning; removing a tag that doesn’t exist, or a system-generated one, returns a validation error. Everything else about the v5.2 endpoint is identical to v5.0.

​
Read the response

299 means the update applied with skipped parts (see warnings); 4030 means nothing changed — including No shipments found with provided shipment_id. when the identifier doesn’t match. See responses and errors.

​
Next steps

  • Retrieve the Shipment to verify the stored state after an update.
  • Order fields (order_reference, order_source_*) require a valid existing order_id — see Orders.