---
title: "Update Work Order Status"
method: PUT
path: "/service_orders/{purchase_order_uid}/status"
---

# Update Work Order Status

`PUT /service_orders/{purchase_order_uid}/status`

## Request

- Base URL: `https://dc-region.zuperpro.com/api`
- URL: `https://dc-region.zuperpro.com/api/service_orders/{purchase_order_uid}/status`
- Auth: API key in header `x-api-key`

Operates on Service Orders, shown in the Zuper client app as "Work Order" (in every industry). Work Orders share the exact same underlying schema and endpoints as Purchase Orders / Material Orders; they're distinguished only by the `purchase_order_type` field (`SERVICE_ORDER` here) and the `/service_orders` route prefix. Status transitions are validated against a fixed transition matrix — an unreachable transition is rejected with 400. `WORK_COMPLETED` is not a valid status for a Purchase Order / Material Order; use `FULFILLED` instead.

## Path parameters

- `purchase_order_uid` string, required

## Request body

- object
  - `purchase_order_status` 'DRAFT' | 'SUBMITTED' | 'APPROVED' | 'REJECTED' | 'CANCELED' | 'SENT_TO_VENDOR' | 'VENDOR_APPROVED' | 'VENDOR_REJECTED' | 'FULFILLED' | 'PARTIALLY_FULFILLED' | 'WORK_COMPLETED' | 'INVOICED' | 'PAID' | 'CLOSED', required
  - `remarks` string
  - `attachments` object[]

## Response `200`

200

- object
  - `type` 'success'
  - `title` string
  - `message` string
  - `data` object: Present only for vendor-integrated suppliers — holds the supplier submission result.

## Changes

- **2026-11-03** `3c21bc232e16`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/zuper/apis/zuper-pro-api/changes/service_orders/:purchase_order_uid/status/put.md)

---

[API](https://skmtc.dev/zuper/apis/zuper-pro-api.md) - [All operations](https://skmtc.dev/zuper/apis/zuper-pro-api/llms.txt) - [OpenAPI document](https://skmtc.dev/zuper/apis/zuper-pro-api/revisions/3c21bc232e16?raw)