update sales order
Changes what a person may change on an order Tightly owns: its ship date, its cancel date, your own reference, the warehouse it will ship from, and its lines. lines names only the lines you are changing, each by its order_line_item_id (as the read serves it) or by variant_id or sku. A quantity of 0 removes one, a variant_id the order does not carry adds one, and a line you do not name is left alone, so two people editing one order do not delete each other's work.
Allowed in draft, open and allocated, and it re-allocates. An order that came from a connected channel is never changed here; change it in the channel. An order whose fulfilment has been requested is refused order_locked_for_fulfilment, and the lock is the order's lifecycle alone: it stands from the moment the request is raised, whether the warehouse has been sent it, is still holding it queued, or failed to take it. A queued request may leave any second and a failed one may be retried, and either would carry the lines as they were before your change.
Read the date in that refusal as the day the request was RAISED. The sentence reads "was sent to <warehouse> on <date>", and the date it names is the order's lifecycle_updated_at, not the moment the warehouse was actually called, which is a separate stamp. cancel_sales_order is the one door that looks at what the warehouse holds: a cancel is allowed from fulfilment_requested while the request is queued or failed.
Scope: orders:write, which includes orders:read.
Request
- Base URL: https://api.app.tightly.io
- URL: https://api.app.tightly.io/api/v1/sales/orders/{order_id}
- Auth: HTTP bearer
Path parameters
The order's id.
Headers
The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.
A string of your own, up to 255 characters, that makes this write safe to retry. Send the same key twice and the second request is answered with the first one's status and body instead of writing again, so a client that retried after a timeout ends holding the record's id rather than creating a second one. Reusing a key with a different body, or while the first request is still running, is refused 409. A write that failed releases its key. Keys answer for 24 hours and belong to the API key that used them. A key longer than 255 characters is ignored and the write goes ahead without the guarantee.
Request body
Response
The order as it now stands. An allocated order the change leaves holding nothing, every line removed, reads open, the lifecycle of an order that holds nothing.
Changes
No recorded changes to this operation across all 1 revision of this API.