Update task

PATCH /v1/tasks/:id

Updates the fields of an existing task. Pass only the fields you want to change. Full list — Task fields.

Parameters

Request fields (body)

Pass only the fields you want to change — that is PATCH behavior. Other values are left unchanged.

The fields id, dateStart, activityDate, realStatus are read-only and cannot be passed in the body.

Task service fields can be set

createdBy (creator), changedBy, closedBy, statusChangedBy, createdDate, changedDate, closedDate are accepted both on create and on update: Bitrix24 stores the submitted values, and Vibecode is a wrapper over it that does not forbid what the platform allows. Both spellings are accepted — createdBy and CREATED_BY alike. Send one of the two rather than both: if both are present in one body, the one that comes later is applied, with no warning.

The value is applied within the permissions of the calling user. When Bitrix24 refuses to edit the task, the refusal is passed through as is — a 422 with Bitrix24's own message, not replaced by an error of ours and never reported as a success.

What the task log shows. Bitrix24 records a change of the creator in the task change log, and the entry shows the actual calling user, not the one passed in createdBy. For the other six fields no such log entry exists: the value in the card does not tell you who set it.

A date without a time zone. For createdDate, changedDate and closedDate, a value like 2019-05-15T13:47:00 sent under the createdDate spelling gets the offset of your time zone from the X-Vibe-Timezone header, while under the CREATED_DATE spelling it is passed through unchanged and read in the key owner's time zone. Send the date with an offset — 2019-05-15T13:47:00+00:00 — and both spellings yield the same instant.

Only the Bitrix24 permission model can restrict overwriting the service fields — that is a separate change on the platform side, not in our wrapper.

Pass an existing employee only. Bitrix24 does not check that the user ID exists in any of createdBy, changedBy, closedBy, statusChangedBy — it stores any number. A task whose creator does not exist stops being manageable through the API: Bitrix24 refuses both further updates and deletion (This task action is not allowed.), through the wrapper and directly alike, even for an administrator key. That outcome was verified on createdBy. The ID is not validated in the other three fields either, so pass an existing employee there too. Employee list: GET /v1/users.

Frequently updated fields

Examples

curl — personal key

curl -X PATCH "https://vibecode.bitrix24.com/v1/tasks/3871" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": 5,
    "priority": 2
  }'

curl — OAuth application

curl -X PATCH "https://vibecode.bitrix24.com/v1/tasks/3871" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "status": 5,
    "priority": 2
  }'

JavaScript — personal key

const res = await fetch('https://vibecode.bitrix24.com/v1/tasks/3871', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    status: 5,
    priority: 2,
  }),
})

const { success, data } = await res.json()

JavaScript — OAuth application

const res = await fetch('https://vibecode.bitrix24.com/v1/tasks/3871', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    status: 5,
    priority: 2,
  }),
})

const { success, data } = await res.json()

Response fields

Response example

{
  "success": true,
  "data": {
    "id": 3871,
    "title": "Prepare the quarterly report",
    "status": 5,
    "priority": 2,
    "responsibleId": 1,
    "createdBy": 1,
    "createdDate": "2026-05-12T11:46:12.000Z",
    "changedDate": "2026-05-12T13:02:48.000Z",
    "closedDate": "2026-05-12T13:02:48.000Z",
    "deadline": "2026-05-19T18:00:00.000Z",
    "accomplices": [],
    "auditors": []
  }
}

Error response example

400 — attempt to change a read-only field:

{
  "success": false,
  "error": {
    "code": "READONLY_FIELD",
    "message": "Field 'activityDate' is read-only and cannot be set"
  }
}

Errors

The full list of common API errors — Errors.

Known specifics

Closing a task. To mark a task as done, send status: 5. After that Bitrix24 fills in closedDate on its own when the task moves to status 5 (completed) or 6 (deferred). You can also pass closedDate manually — see the service-fields section above. When the field is omitted, the platform sets it for you.

See also

• Get task
• Task fields
• Delete task
• List tasks
• Upload file
• Batch
• Limits and optimization