API Яндекс Диска связывает файлы со сделкой в CRM, а агенты проверяют версии и права доступа

Возьмём условный проект B2B-компании: менеджер ведёт сделку в CRM, инженер складывает расчёты на Диск, клиенту отправляют договор и смету. Папка с названием клиента помогает найти документы. Но сама по себе она не говорит, какой договор согласован и относится ли смета к этой сделке.

Для такой задачи не обязательно строить свою CRM. Если действующая CRM позволяет читать сделку и записывать связанные данные через API, можно добавить файловую связку. Возможности конкретной CRM проверяют до оценки разработки: название продукта ещё не доказывает, что нужные действия доступны.

В карточке сделки хранится запись о документе: идентификатор сделки, расположение файла, его назначение, версия и статус согласования. При открытии CRM показывает эту запись. После загрузки интеграция сверяет её с Диском. Если папку переименовали или доступ пропал, в сделке появляется ошибка, которую можно разобрать.

Номер сделки можно также записать в пользовательские свойства файла на Диске: API поддерживает такие свойства. Это дополнительная метка для сверки. Одна метка не заменяет запись в CRM и правило, которое запрещает незаметно привязать документ к другой сделке.

Название «договор_финальный» не защищает от старой копии. При загрузке API позволяет запретить перезапись или заменить файл с тем же именем. По умолчанию перезапись запрещена. Это механизм записи, а не готовое правило согласования договора.

Если для бизнеса важен возврат к принятому документу, безопаснее сначала сохранить новую версию отдельно. В CRM она получает статус «на проверке». После согласования её отмечают как принятую. Если решено перезаписывать один файл, до разработки нужно определить, где хранится прежняя версия и как её восстановить.

Сверять только имя недостаточно. API возвращает метаданные файла, в том числе дату изменения, размер и контрольную сумму MD5. По этим данным связка может заметить замену содержимого. Метаданные помогают сверке, но не доказывают, что клиент согласовал именно этот текст.

Ещё одна поломка выглядит как успех: сервер принял загрузку, связь оборвалась, CRM отправила тот же запрос снова. Интеграции нужен свой идентификатор попытки и проверка результата на Диске. Иначе появятся дубли или сообщение «готово» раньше, чем файл доступен. Документация допускает ответ «принят, но ещё не перенесён на Диск».

Сначала выясняют, где лежат документы: на личном Диске сотрудника, в общей папке или на общем диске организации. Общий диск Яндекс 360 принадлежит организации; доступ сотрудников, групп и подразделений настраивает администратор. REST API использует составные пути к ресурсам общего диска.

OAuth-токен даёт приложению разрешённые действия. Он не переносит автоматически роли из CRM на Диск. Если менеджер видит сделку, это ещё не доказывает право читать её файлы. Нужно согласовать обе стороны: кто видит документ в CRM и от чьего имени интеграция обращается к хранилищу.

Ограничение папкой приложения подходит для файлов, которые приложение хранит в своей папке. Оно не открывает существующий архив компании. Выбор такого доступа выглядит осторожным, но может сделать задачу невыполнимой. Правила для агентов должны задавать разрешённые действия и границы доступа к рабочим документам.

Публичная ссылка создаётся только по согласованному правилу клиента, записанному в его репозитории. API умеет публиковать ресурс и закрывать публикацию. Кнопка «отправить» сама не даёт разрешения открыть договор. В приёмку включают и отказ в публикации, и закрытие уже выданной ссылки.

Наш опыт здесь относится к разработке vibecoding.ru. В открытом журнале разработки на 8 октября 2026 года показано 7 107 коммитов за 99 дней, с 1 июля. Это объём работы машины сайта. Он не измеряет стоимость файловой интеграции и не доказывает, что любая задача выполняется без ошибок.

Клиентского кейса связки Яндекс Диска с CRM у нас нет. В уроках агентной разработки разбираем правила, задачи и проверки, в том числе урок «Руль, окно и сторож». Из разработки сайта можно перенести способ работы и известные ошибки. Результат новой интеграции придётся подтвердить отдельно.

Постановка содержит исходные условия и результат, который можно проверить. В разборе задачи для агента этот принцип показан подробнее. Здесь задача звучит так: «Повтор события загрузки не добавляет второй документ; новая версия не получает статус принятой без согласования». Затем агент пишет код и проверку, а инженер смотрит, обнаруживает ли она ошибку.

Ошибки собственной машины подсказали, что проверить до доступа к документам клиента. Мы уже сталкивались с ключом не той учётной записи, секретом в транскрипте и полем, потерянным при переносе данных. Это случаи из почтового и новостного контуров сайта, а не поломки внедрённой CRM-связки.

Демонстрация «нажали кнопку, файл появился» проверяет только один путь. В нашем условном проекте договор ещё нужно принять, прикрепить к нужной сделке и открыть нужному адресату. Поэтому приёмка начинается с набора документов и ролей, для которых заранее записан ожидаемый результат.

Для разработки можно использовать вымышленные сделки и пустые образцы договоров. Рабочие документы не нужны агенту, чтобы написать обработку повторов и проверку роли. Инженер подключает выбранную среду и разрешённые учётные записи, а агент получает только необходимые данные и команды.

В нашем условном проекте менеджер должен видеть в сделке принятый договор или причину отказа. Если на Диске пропал доступ или закончилось место, связка записывает сбой и даёт повторить действие после исправления причины. Ошибка не должна исчезать в журнале, который менеджер никогда не открывает.

Так замыкается рабочая петля: действие в сделке, проверка на Диске, результат в CRM, исправление причины и повтор. Чтобы обсудить задачу руководителя, достаточно описать один такой путь и принести примеры разрешённого и запрещённого доступа. Вспоминать весь архив компании на первом разговоре не требуется.

На странице разработки по подписке на 8 октября 2026 года тариф «Один проект» стоит 250 000 ₽ в месяц. Инженер ведёт машину агентов: пишет связку папки и файлов со сделкой, проверяет разрешения, повтор загрузки и замену версии. Код поступает в репозиторий клиента.

В работе одна задача, следующая ждёт в очереди. Подписку можно поставить на паузу в любой месяц. Фикс за месяц не равен цене одной интеграции. Из него нельзя вывести срок подключения конкретной CRM, пока не проверены её API, схема Диска и критерии приёмки.

До начала работы отдельно считают лицензии сервисов и их комиссии. В смете нужно разделить разработку и расходы на CRM, хранилище и эксплуатацию связки. В статье нет цены этих сервисов: они зависят от выбранных продуктов, тарифов и договора клиента.

Первой задачей может стать один вид документа и один путь его согласования. Например, договор прикрепляется к сделке, новая версия ждёт решения, повтор не создаёт дубль, ссылка выдаётся только по записанному правилу. Это граница для обсуждения. Согласованный объём и срок появляются после проверки исходных условий.

1. Зафиксируйте владельца Диска, номер сделки и назначение каждого документа.
2. Отделите загрузку новой версии от её согласования и выдачи клиенту.
3. Примите связку на повторе, потере доступа и закрытии публичной ссылки.
4. Согласуйте объём первой задачи; бюджет месяца и расходы сервисов считайте отдельно.