# Связи задач

Связи задачи — это её **предшественники**: задачи, от которых она зависит. Методы подраздела читают связи одной задачи и до 50 задач одним вызовом.

Битрикс24 API: `tasks.task.get` (поле `RELATED_TASKS`)
Скоуп: `task`

## Операции

- [Связи задачи](./dependencies-list.md) — `GET /v1/tasks/:taskId/dependencies`
- [Связи нескольких задач](./dependencies-bulk.md) — `POST /v1/tasks/dependencies/bulk`

## Ключевые поля

Связь в ответе обоих методов — пара полей.

| Поле | Описание |
|------|----------|
| `id` | ID задачи-предшественника. Получить: [`GET /v1/tasks/:id`](/docs/entities/tasks/get) |
| `title` | Название задачи-предшественника. `null`, если портал его не отдал |

## Что нужно знать перед работой

1. **Отдаются только предшественники.** Обратного направления — «кто зависит от этой задачи» — нет. Чтобы построить граф целиком, прочитайте связи всех задач [пакетным вызовом](./dependencies-bulk.md) и сами составьте обратные пары: если задача A зависит от B, то B — предшественник A.
2. **Тип связи не возвращается.** В ответе только `id` и `title` предшественника, без типа вроде «финиш — старт».
3. **Видны только связи из поля `DEPENDS_ON`.** Методы читают тот же набор предшественников, который записывает поле `DEPENDS_ON` задачи. В Битрикс24 этот набор отдаётся полем `RELATED_TASKS`. Связи с типом вроде «финиш — старт» Битрикс24 хранит отдельно от этого набора, и в ответ они не попадают. Поэтому пустой ответ не доказывает, что у задачи нет связей совсем.
4. **Запись — через обновление задачи.** Отдельного метода записи в подразделе нет. Набор предшественников задаёт поле `DEPENDS_ON` в теле [`PATCH /v1/tasks/:id`](/docs/entities/tasks/update): переданный список заменяет прежний целиком, пустой список `[]` убирает все связи. Задачу нельзя сделать предшественником самой себя — такой запрос отвечает `422 BITRIX_ERROR`.
5. **В списке задач связей нет.** [`GET /v1/tasks`](/docs/entities/tasks/list) не отдаёт поле связей: на `dependsOn` в `select` приходит предупреждение `UNKNOWN_SELECT_FIELD`.
6. **Ключ только для чтения читает связи** — оба метода, включая пакетный вызов через `POST`.

## Типичный сценарий

1. Найти задачи: [`GET /v1/tasks`](/docs/entities/tasks/list).
2. Прочитать связи одной задачи: [`GET /v1/tasks/:taskId/dependencies`](./dependencies-list.md), или нескольких сразу: [`POST /v1/tasks/dependencies/bulk`](./dependencies-bulk.md).
3. Изменить набор предшественников: поле `DEPENDS_ON` в [`PATCH /v1/tasks/:id`](/docs/entities/tasks/update).

## Лимиты

| Лимит | Значение |
|-------|----------|
| Связей у одной задачи | До 1000. Ответ не усекается: при большем числе связей одиночный вызов отвечает `422 DEPENDENCY_LIMIT_EXCEEDED`, а пакетный кладёт этот код в `data.errors` для такой задачи |
| Задач в пакетном вызове | До 50 уникальных ID и до 500 элементов в исходном массиве |
| Частота пакетного вызова | 30 запросов в минуту на портал, общий для всех ключей портала. Лимит делится между репликами платформы: действующее значение — в заголовке `x-ratelimit-limit` |
| Частота одиночного вызова | Общие лимиты API — [Лимиты и оптимизация](/docs/optimization) |

## Смотрите также

- [Задачи](/docs/entities/tasks)
- [Обновить задачу](/docs/entities/tasks/update)
- [Чек-лист задачи](/docs/entities/tasks/checklist)
- [Учёт времени задач](/docs/entities/tasks/time)