Update a device handling intent
Change what happens to the leaver devices and accessories, or the return shipment request, before the intent executes; read the current proposal with getDeviceHandlingIntent. devices and accessories are each replaced whole; null leaves a field as it is. Each device and accessory of the leaver goes back in stock (PUT_BACK_IN_STOCK), to a new owner (REASSIGN) or out of the fleet (DECOMISSION), with an optional MDM action on its data (data: WIPE, LOCK…). Item ids come from getEmployee of the leaver (deviceIds, accessoryIds). Only the fields you send change. Refused with INTENT_NOT_FOUND, INTENT_ALREADY_EXECUTED once executed, TICKET_CLOSED when its task is completed or cancelled, EXECUTION_IN_PROGRESS, DEVICE_NOT_OWNED_BY_EMPLOYEE, ACCESSORY_NOT_OWNED_BY_EMPLOYEE, REASSIGN_OWNER_REQUIRED, REASSIGN_OWNER_IS_LEAVER, REASSIGN_OWNER_NOT_FOUND.
Authorizations
Use your Primo API key in the Authorization header as Bearer <API_KEY>.
Path Parameters
Body
Response
Intent id, to pass to its update and execute tools
The typed task that tracks this step
The ticket holding that task, usually the offboarding ticket. Null if it could not be read back.
When the intent executed; null until then
^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$