Take a refused order file as the new draft
Takes a paper Tightly refused and makes it the order instead. Use it when a retailer sends the same order number again with different lines: the first draft still stands, and this cancels it with the reason and reads the newer paper in its place, in one call.
Re-sending the file cannot do this: those bytes are already on the refused paper, so Tightly would answer that it already has them and create nothing.
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/documents/{document_id}/take
- Auth: HTTP bearer
Path parameters
The order file's id, as List order documents serves it.
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.
Response
The paper, read again, with the draft it now carries, in the same whole shape GET /sales/orders/documents/{document_id} serves: the reading, the matcher's answer per document line, the source to check it against, and the account. The example shows the fields the take moves rather than the whole answer.
Changes
No recorded changes to this operation across all 1 revision of this API.