Apply counted quantities to an open count from an uploaded CSV or Excel file
Applies a whole file of counts to an open count. The body is s3_key, a file already uploaded through the shared presigned-URL flow, and mappings, a {our_field: their_header} object in the same shape GET /files/mappings returns. sku and counted_quantity are both required in the mapping; location is optional.
Rows match the count's lines on SKU, case-insensitively and ignoring surrounding spaces, and on location name as well when a location column is mapped. A SKU held at several locations in the count's scope with no location column is reported in unmatched_skus rather than guessed at: putting a count on the wrong shelf is worse than not putting it anywhere.
The response is a summary, not the lines: updated is how many lines took a count, skipped is how many rows were readable but changed nothing, and unmatched_skus lists what the file names and the count ignored, a SKU outside the scope, or an ambiguous one. A quantity that is not a number is skipped, not zeroed.
Refused 400 once the count is posted. To set a handful of lines without a file, use update_stocktake_counts.
Scope: stocktakes:write, which includes stocktakes:read.
Request
- Base URL: https://api.app.tightly.io
- URL: https://api.app.tightly.io/api/v1/stocktakes/{stocktake_id}/import
- Auth: HTTP bearer
Path parameters
The open count the file's rows apply to.
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
What the file changed, and what it names that the count does not cover.
Changes
No recorded changes to this operation across all 1 revision of this API.