# Pull Items into Job

Moves an item out of the folder it currently sits in and into the job's folder. It
does not create anything: pass the item_id of any existing item in your account
along with the quantity to move, and that quantity is relocated onto the job.

Up to 100 items per request, and they may sit in different folders, which makes this
the practical way to record a batch of usage in one call.
POST /items/{item_id}/move performs the same action one item at a time.

Items land in the job's folder itself, never in a subfolder. Even when the job
was created with subfolders, everything arrives at the top level of the job folder.
To file an item into a particular subfolder, move it again afterwards with
POST /items/{item_id}/move and folder_id set to that subfolder.

Items are processed independently, so a failure on one does not reject the rest and
a partial failure still returns 200. Always check data.errors rather than relying
on the status code, and retry only the items listed there.

Moving part of a quantity splits the item, so an id in added_item_ids can differ
from the one you sent. Pulling items into a completed job returns 403.

Endpoint: POST /api/v1/jobs/{job_id}/items
Security: BearerAuth

## Path parameters:

  - `job_id` (number, required)
    ID of the job
    Example: "101"

## Request fields (application/json):

  - `items` (array, required)
    1 to 100 items per request.

  - `items.item_id` (number, required)
    ID of the item to move onto the job.

  - `items.quantity` (number, required)
    Quantity to move.

  - `items.item_version` (number)
    The version from the last read of the item. A stale version is rejected.

  - `items.leave_zero_quantity` (boolean)
    Keep a zero-quantity copy of the item in its original folder. Default is false.

  - `action` (object, required)
    The action reason recorded in each item's history. Required on this endpoint.

  - `action.reason_id` (string, required)
    UID of a move-type action reason. Required: without it the call is rejected with 400 A reason is required for this action type, and that holds even if you send action with only notes in it. Every account carries Sortly's default move reason Added to Job, e36df891-596f-42a2-a561-3d127d9fa080, which is the one to send unless you have your own. A receive-type reason is rejected with 400 Reason type does not match action type, an unknown one with 400 Reason not found, and a non-UUID with 400 Bad Request.

  - `action.notes` (string)

## Response 200 fields (application/json):

  - `data` (object)

  - `data.added_item_ids` (array)
    Items now on the job. Moving part of a quantity splits the item, so an ID here can differ from the one sent

  - `data.errors` (array)

  - `data.errors.item_id` (number)

  - `data.errors.name` (string)

  - `data.errors.error` (string)

## Response 400 fields (application/json):

  - `message` (string)

  - `errors` (object,null)

## Response 401 fields (application/json):

  - `message` (string)

  - `errors` (object,null)

## Response 403 fields (application/json):

  - `message` (string)

  - `errors` (object,null)

## Response 404 fields (application/json):

  - `message` (string)

  - `errors` (object,null)

## Response 409 fields (application/json):

  - `message` (string)

  - `errors` (object,null)

## Response 429 fields (application/json):

  - `message` (string)