confirm sales order
Records what you are agreeing to on every line of a draft order and opens it, or moves it straight to allocated where the organisation holds stock for orders. Each line is accepted as asked, accepted at a different quantity, or rejected; every line must carry one, so nothing is agreed to on your behalf. On an order that arrived over EDI the acknowledgement (855) goes back to the account where they take one, and where they do not the decision is recorded and nothing is sent. A line the account named with a code that is not on their product list has to be matched or rejected first; until it is, the confirm is refused with how many lines are waiting.
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}/confirm
- 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, open, with every verdict on its lines.
Changes
No recorded changes to this operation across all 1 revision of this API.