# Task dependencies

A task's dependencies are its **predecessors**: the tasks it depends on. The methods in this subsection read the dependencies of one task, or of up to 50 tasks in one call.

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

## Operations

- [Dependencies of one task](./dependencies-list.md) — `GET /v1/tasks/:taskId/dependencies`
- [Dependencies of several tasks](./dependencies-bulk.md) — `POST /v1/tasks/dependencies/bulk`

## Key fields

In the response of both methods, a dependency is a pair of fields.

| Field | Description |
|------|----------|
| `id` | ID of the predecessor task. Get: [`GET /v1/tasks/:id`](/docs/entities/tasks/get) |
| `title` | Name of the predecessor task. `null` if Bitrix24 did not return it |

## What to know before you start

1. **Only predecessors are returned.** The reverse direction — "who depends on this task" — is not available. To build the whole graph, read the dependencies of all tasks with a [bulk call](./dependencies-bulk.md) and build the reverse pairs yourself: if task A depends on B, then B is a predecessor of A.
2. **The dependency type is not returned.** The response carries only the predecessor's `id` and `title`, with no type such as "finish-to-start".
3. **Only dependencies from the `DEPENDS_ON` field are visible.** The methods read the same set of predecessors that the task's `DEPENDS_ON` field writes. Bitrix24 returns this set in the `RELATED_TASKS` field. Bitrix24 stores typed dependencies such as "finish-to-start" separately from this set, and they do not appear in the response. So an empty response does not prove that the task has no dependencies at all.
4. **Writing goes through a task update.** The subsection has no separate write method. The set of predecessors is defined by the `DEPENDS_ON` field in the body of [`PATCH /v1/tasks/:id`](/docs/entities/tasks/update): the list you send replaces the previous one entirely, and an empty list `[]` removes all dependencies. A task cannot be made its own predecessor — such a request returns `422 BITRIX_ERROR`.
5. **The task list carries no dependencies.** [`GET /v1/tasks`](/docs/entities/tasks/list) does not return the dependencies field: `dependsOn` in `select` produces an `UNKNOWN_SELECT_FIELD` warning.
6. **A read-only key can read dependencies** — with both methods, including the bulk call via `POST`.

## Typical scenario

1. Find tasks: [`GET /v1/tasks`](/docs/entities/tasks/list).
2. Read the dependencies of one task: [`GET /v1/tasks/:taskId/dependencies`](./dependencies-list.md), or of several tasks at once: [`POST /v1/tasks/dependencies/bulk`](./dependencies-bulk.md).
3. Change the set of predecessors: the `DEPENDS_ON` field in [`PATCH /v1/tasks/:id`](/docs/entities/tasks/update).

## Limits

| Limit | Value |
|-------|----------|
| Dependencies per task | Up to 1000. The response is not truncated: above that, the single call returns `422 DEPENDENCY_LIMIT_EXCEEDED`, and the bulk call puts this code in `data.errors` for that task |
| Tasks in a bulk call | Up to 50 unique IDs and up to 500 elements in the original array |
| Bulk call rate | 30 requests per minute per Bitrix24 account, shared by all keys of the account. The limit is divided across the platform's replicas: the effective value is in the `x-ratelimit-limit` header |
| Single call rate | General API limits — [Limits and optimization](/docs/optimization) |

## See also

- [Tasks](/docs/entities/tasks)
- [Update task](/docs/entities/tasks/update)
- [Task checklist](/docs/entities/tasks/checklist)
- [Task time tracking](/docs/entities/tasks/time)