List comments

GET /v1/tasks/:taskId/comments

Returns the comments of a specific task. On the new task card the list is read from the chat; system messages are filtered out. On the old card it is read from the comments block inside the card.

Comments written before the Bitrix24 account moved to the new task card do not migrate into the chat, so a task that has a chat can still keep part of its comments in the legacy store. When the chat is read to its end and yields no comment at all, the list reads the legacy store and answers from it; when the chat yielded nothing and could not be read to its end either, the legacy store is still read, but the chat is not listed in meta.sources. meta.sources names the stores whose contents this response learned, while meta.truncated reports whether what was read is complete: together they tell you whether an empty data means that the task has no comments or that only one of the two stores was heard from.

Parameters

Examples

curl — personal key

curl "https://vibecode.bitrix24.com/v1/tasks/289/comments?limit=20&sort=id:desc" \
  -H "X-Api-Key: YOUR_API_KEY"

curl — OAuth application

curl "https://vibecode.bitrix24.com/v1/tasks/289/comments?limit=20&sort=id:desc" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN"

JavaScript — personal key

const url = 'https://vibecode.bitrix24.com/v1/tasks/289/comments?limit=20&sort=id:desc'
const res = await fetch(url, {
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
  },
})

const { success, data, meta } = await res.json()
console.log(`Received ${data.length} comments`)

JavaScript — OAuth application

const url = 'https://vibecode.bitrix24.com/v1/tasks/289/comments?limit=20&sort=id:desc'
const res = await fetch(url, {
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

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

Response fields

Response example

{
  "success": true,
  "data": [
    {
      "id": 36559,
      "taskId": 289,
      "authorId": 1,
      "message": "Added a draft of the report to the comments — please take a look.",
      "createdAt": "2026-05-13T12:30:58.000Z",
      "attachments": []
    },
    {
      "id": 36557,
      "taskId": 289,
      "authorId": 79,
      "message": "[USER=99]Alex[/USER], done, thanks.",
      "createdAt": "2026-05-12T15:11:04.000Z",
      "attachments": []
    }
  ],
  "meta": {
    "total": 2,
    "hasMore": false,
    "sources": ["chat"]
  }
}

An example of a comment with a non-empty attachments — Get comment.

Error response example

400 — taskId is not a positive integer:

{
  "success": false,
  "error": {
    "code": "INVALID_PARAMS",
    "message": "taskId must be a positive integer"
  }
}

Errors

Full list of common API errors — Errors.

Known specifics

Scan window when filtering. On the new card a request with filter or a sort other than ID scans up to 2000 of the newest task chat messages, system notifications included, and picks the matching comments out of them. If the task history is longer, or is limited by the Bitrix24 account plan, the response carries meta.truncated: true: comments that are not in the response remained beyond the window edge, and meta.total counts only the ones inside it. This is not a sign of a next page — offset does not move the window. Narrow the selection with a POST_DATE or AUTHOR_ID filter. For the same reason ?sort=post_date:asc on such a task returns the oldest comments within the window, not the oldest comments of the task.

Filter and sort by author — via AUTHOR_ID. The fields AUTHOR_NAME and AUTHOR_EMAIL are accepted on the old card and return 400 on the new one, so a request by author name does not work on every Bitrix24 account. To make the selection independent of how the Bitrix24 account is configured, find the employee via GET /v1/users and filter or sort by AUTHOR_ID.

The list reads the chat whenever the task has one. When a task has a chat, the response is assembled from its messages. Comments written before the Bitrix24 account moved to the new card were never migrated into the chat, so when the chat holds no comment of its own the list reads the legacy comment block of the old card and answers from it — meta.sources names the stores it actually read. Getting a comment by identifier and downloading an attachment check both stores, but they do NOT guarantee a hit: the lookup goes chat-first, and chat identifiers and old-card identifiers live in separate spaces that overlap numerically, so on a task holding both stores the same number can match a different chat comment and the request never reaches the old card. See "A matching number means nothing" in Download an attachment; take a reliable id from a response of the same store rather than from somewhere else. If you know the id, use Get comment instead of relying on the list.

System notifications and the end of the list. System notifications about task creation, deadline change and assignee change are filtered out on the API side. When a slice consists only of them, the service reads further into the task history instead of answering an empty page that invites more paging: meta.hasMore: false with meta.total: 0 means the source that was read really holds no comments — that is, system notifications do not explain the empty answer. meta.sources tells you whether the task itself has none — only ["chat", "legacy"] is conclusive, see the next item. Such a task used to answer {"data": [], "total": 1, "hasMore": true} at every offset, so a while (hasMore) offset += limit loop never ended. Paginate by meta.hasMore and the contents of data.

Read an empty data through meta.sources together with meta.truncated. A conclusive "the task has no comments" comes from the set ["chat", "legacy"] with no meta.truncated: the contents of both stores are known and both are empty. The same set with truncated: true means not everything was read — including when the legacy store returned a full page and more comments may sit behind it. Any other set means some store was not read, and an empty data says nothing about it. ["legacy"] — the chat did not answer: it refused (no im scope, the method is unavailable), the form of its reply could not be parsed, or the scan broke off. A task that has NO chat yields this set only within the five-minute cache, where the absence of a chat is indistinguishable from an unparsed reply; on a FRESH check its chat store is provably empty and the answer carries the full set. ["chat"] — the legacy store was not read: the chat returned at least one comment, in which case the follow-up read never starts, or that read failed. [] — neither answered. The status stays 200 in every case: the endpoint returns what it learned and names it, instead of failing a request that worked or passing silence off as an answer.

See also

• Get comment
• Create comment
• Batch operations
• Tasks
• Limits and optimization