For AI agents: markdown of this page — /docs-content-en/entities/tasks/update.md documentation index — /llms.txt

Update task

PATCH /v1/tasks/:id

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

Parameters

Parameter	Type	Req.	Description
`id` (path)	number	yes	Task ID

Request fields (body)

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

Field	Type	Description
`title`	string	Title
`description`	string	Task description (supports BB-code)
`responsibleId`	number	New responsible person. Employee list: `GET /v1/users`
`createdBy`	number	New creator. Applied within the permissions of the calling user. An existing employee only — see the warning below the table. Employee list: `GET /v1/users`
`status`	number	Task status. Full value list: `GET /v1/tasks/fields` → `fields.status.enum`
`priority`	number	Priority: `0` — low, `1` — normal, `2` — high
`deadline`	datetime	Deadline (ISO 8601)
`startDatePlan`	datetime	Planned start date
`endDatePlan`	datetime	Planned end date
`timeEstimate`	number	Effort estimate in seconds
`groupId`	number	Workgroup. List: `GET /v1/workgroups`
`parentId`	number	Parent task. List: `GET /v1/tasks`
`accomplices`	number[]	Participants. Employee list: `GET /v1/users`
`auditors`	number[]	Observers. Employee list: `GET /v1/users`
`tags`	string[]	Task tags
`ufTaskWebdavFiles`	string[]	Task files. An array of strings shaped as `n<id>`, where `id` is the file identifier from the `POST /v1/files/upload` response. A write replaces the whole attachment list. An empty array removes every attachment. The full rule for file fields — Task fields
`changedBy`	number	Service field: who changed the task last. Accepted on write — see the section below the table. Employee list: `GET /v1/users`
`closedBy`	number	Service field: who closed the task. Accepted on write — see the section below the table. Employee list: `GET /v1/users`
`statusChangedBy`	number	Service field: who changed the status last. Accepted on write — see the section below the table. Employee list: `GET /v1/users`
`createdDate`	datetime	Service field: task creation date, ISO 8601. Accepted on write — see the section below the table
`changedDate`	datetime	Service field: last change date, ISO 8601. The value you send is stored instead of the current time — see the section below the table
`closedDate`	datetime	Service field: closing date, ISO 8601. Accepted on write even for a task that is not closed — see the section below the table

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

The 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 keeps the real calling user rather than 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 — neither in createdBy nor in changedBy, closedBy, statusChangedBy. It stores any number. A task whose creator does not exist stops being manageable through the API: Bitrix24 refuses both a further update and a deletion (Action on the task 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

Field	When used
`status`	Closing (`5`), returning to work (`3`), declining (`7`). Value reference: `GET /v1/tasks/fields` → `fields.status.enum`
`responsibleId`	Reassigning the task to another employee. Source: `GET /v1/users`
`deadline`	Rescheduling the deadline (ISO 8601 with the Bitrix24 account's time zone offset)

Examples

curl — personal key

Terminal

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

Terminal

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

javascript

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

javascript

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

Field	Type	Description
`success`	boolean	Always `true` on success
`data`	object	The updated task object with all fields — see Task fields

Response example

JSON

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

Error response example

400 — attempt to change a read-only field: