Task dependencies

A task's dependencies are its predecessors: the tasks it depends on. The Bitrix24 task card shows them in the "Related tasks" block. This resource is read-only.

Bitrix24 API: tasks.task.get (the RELATED_TASKS field) Scope: task

Operations

• GET /v1/tasks/:taskId/dependencies — dependencies of one task
• POST /v1/tasks/dependencies/bulk — dependencies of up to 50 tasks in one call

What to know before integrating

Only predecessors are returned. The reverse edge — "who depends on this task" — is returned by no Bitrix24 REST method at all. A dashboard that needs the whole graph builds the reverse edges itself, by inverting the pairs it collected. That is what the bulk call is for: collecting pairs for a hundred tasks in one request is cheaper than in a hundred requests.

The dependency type is not readable. A Bitrix24 dependency has a type (finish-to-start, for example), but no REST method returns it. So the type field is not published here at all: an empty or guessed value in a contract is worse than its absence.

Dependencies created by the Gantt method are invisible. Bitrix24 keeps dependencies in two places. The regular ones — written when the task is created or updated — are readable. Dependencies added with task.dependence.add do exist physically, but no read method returns them, task.item.getdependson included. Telling "there are no dependencies" apart from "there are dependencies, but in the invisible store" is impossible — through this API and through raw REST alike.

The task list carries no dependencies. GET /v1/tasks and POST /v1/tasks/search do not return the field: Bitrix24 silently drops it from a list response regardless of the select. Hence a separate resource.

A task may reference itself. When it does, the self-loop arrives as is — that is a fact from the Bitrix24 account, not a response error. A dashboard that builds the graph by inverting pairs has to be ready for it.

One task — `GET /v1/tasks/:taskId/dependencies`

curl -H "X-Api-Key: $KEY" \
  "https://vibecode.bitrix24.com/v1/tasks/4029/dependencies"

{
  "success": true,
  "data": [
    { "id": 4023, "title": "Draft the estimate" },
    { "id": 4027, "title": "Approve the budget" }
  ],
  "meta": { "total": 2, "hasMore": false, "direction": "predecessors", "source": "RELATED_TASKS" }
}

Records are sorted by id ascending. title may be null — the Bitrix24 account did not return a name for that task. meta.total always equals the length of data.

A transient failure on the Bitrix24 side — an exceeded request rate, an unavailable Bitrix24, an expired token — arrives with its own code rather than being disguised as TASK_NOT_FOUND.

Bulk call — `POST /v1/tasks/dependencies/bulk`

curl -X POST -H "X-Api-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"taskIds": [4029, 4033, 4041]}' \
  "https://vibecode.bitrix24.com/v1/tasks/dependencies/bulk"

{
  "success": true,
  "data": {
    "results": { "4029": [ { "id": 4023, "title": "Draft the estimate" } ], "4033": [] },
    "errors":  { "4041": { "code": "TASK_NOT_FOUND", "message": "Task not found." } }
  },
  "meta": { "requested": 3, "succeeded": 2, "failed": 1, "direction": "predecessors", "source": "RELATED_TASKS" }
}

taskIds accepts both numbers and decimal strings: ["4029"] is equivalent to [4029].

The response carries 200 even when every sub-call failed. Partial failure is the point of a bulk call, so what has to be checked is errors, not only results.

Duplicates collapse silently, and meta.requested counts unique ids. That is why requested always equals succeeded + failed. The position in an INVALID_PARAMS message, however, is counted in the original array — two different coordinate systems in one response, and both are named on purpose.

The codes in errors are a closed set:

Whole-request refusals:

The bulk call is rate-limited per Bitrix24 account, not per key: two keys of the same account share one bucket, so a second key will not raise the ceiling. Over the limit it answers 429; the current limit and Retry-After are in the response body.

The Content-Type: application/json header is required when the body is not empty. An empty body and a request with no header are handled normally and answer INVALID_REQUEST.

Writing dependencies

There is no separate write endpoint. The dependency set is changed through the DEPENDS_ON field in task update, and the semantics there are a full replacement of the set rather than an addition: the list you send displaces the previous one entirely, and an empty list clears the dependencies.

See also

• Tasks
• Task checklist
• Task time tracking