---
title: "Update"
method: PATCH
path: "/operations/operations_tasks/v1/{task_id}"
tags: ["/operations/operations_tasks"]
---

# Update

`PATCH /operations/operations_tasks/v1/{task_id}`

Updates editable fields (task_type, title, description, deadline_timestamp, assigned_user_ids) on an OperationsTask. | authz: min_org_role=operator | (OperationsTaskClientUpdate1) -> (bool)

## Path parameters

- `task_id` string, required

## Request body

- OperationsTaskClientUpdate1
  - `task_type` 'review_order_details' | 'flight_check' | 'facility_check' | 'weather_check' | 'book_cargo' | 'track_and_verify' | 'contact_customer' | 'contact_agent' | 'contact_airline' | 'contact_other' | 'finalize_billing' | 'custom' | 'other' — Coarse functional buckets a dispatcher batch-processes (powers the per-type functional-queue index). Granular SOP specifics live in the Task's `title`/`description`, not here. Ordered roughly along the shipment lifecycle (review -> research -> book -> track/verify -> contact -> billing). The buckets are the distinct *modes of work* an operator sits down and batches; the exact SOP step (e.g. "Send Shipping Label", "CBC Call", "Get Pack Time") is captured in the title. Contact is split by *who* (customer, agent, airline, other), not by *channel* (call vs. email) — the recipient is what a dispatcher batches around, and the channel is captured in title/description detail.
  - `title` string, nullable
  - `description` string, nullable
  - `deadline_timestamp` string, date-time, nullable
  - `assigned_user_ids` string[]

## Response `200`

Successful Response

- boolean

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/chrt/apis/chrt-fastapi.md) · [All operations](https://skmtc.dev/chrt/apis/chrt-fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/chrt/chrt-fastapi/revisions/ea04e157edb3/schema)