One order file, its reading and the source to check it against
One purchase order as it arrived, and what Tightly read off it: the header facts, a line per garment with the codes as printed, and where on the paper each figure was read from, a page and the passage cited on it or a sheet row and column. source.url is a short lived link to the paper itself, so a person can stand the extracted lines beside it.
matched says which rung answered for each printed row: the account's own code, a barcode, your SKU, a pack code or a size grid row. unmatched_lines is how many rows still wait on somebody; while it is above zero, confirming the draft is refused.
Scope: orders:read.
Request
- Base URL: https://api.app.tightly.io
- URL: https://api.app.tightly.io/api/v1/sales/orders/documents/{document_id}
- 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.
Response
The paper, whole. Alongside the fields below the answer carries reading, the reader's own stored frame, which facts, lines, matched and header_match are each drawn from and which also holds the totals it tied and the pages it read. The example leaves it out for length rather than because it is absent; where you want one field, read the four above it, and where you want the reading as the reader wrote it, read reading.
Changes
No recorded changes to this operation across all 1 revision of this API.