Update user taskAdded in 8.5

PATCH 
/user-tasks/:userTaskKey

Strongly Consistent About endpoint data consistency

Update a user task with the given key. Updates wait for blocking task listeners on this lifecycle transition. If listener processing is delayed beyond the request timeout, this endpoint can return 504. Other gateway timeout causes are also possible. Retry with backoff and inspect listener worker availability and logs when this repeats.

Required permissions

When authorization is enabled, this endpoint requires the following permission. See resources and permissions to learn more.

Resource type	Permission
PROCESS_DEFINITION · UPDATE_USER_TASK or USER_TASK · UPDATE

Request

Responses

204

The user task was updated successfully.

400

The provided data is not valid.

404

The user task with the given key was not found.

409

The user task with the given key is in the wrong state currently. More details are provided in the response body.

500

An internal error occurred while processing the request.

503

The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains RESOURCE_EXHAUSTED. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .

504

The request timed out between the gateway and the broker. For these endpoints, this often happens when user task listeners are configured and the corresponding listener job is not completed within the request timeout. Common causes include no available job workers for the listener type, busy or crashed job workers, or delayed job completion. As with any gateway timeout, general timeout causes (for example transient network issues) can also result in a 504 response. Troubleshooting: - verify that job workers for the listener type are running and healthy - check worker logs for crashes, retries, and completion failures - check network connectivity between workers, gateway, and broker - retry with backoff after transient failures - fail without retries if a problem persists