API Диадока связывает документы и их статусы с заказом, а агенты дописывают технический обмен

Для учебного примера возьмём заказ на оптовую поставку. К нему относятся счёт и УПД. Файл без привязки заставит сотрудника искать нужную поставку вручную.

Документ в API задаётся парой MessageId и EntityId. Для запроса содержимого нужен ещё BoxId ящика организации. Номер документа на печатной форме эту связь не заменяет.

Интеграция СБИС с заказами возвращает статусы документов через согласованный обмен по API.

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

Статус нужно переводить в язык заказа по согласованным правилам. Диадок различает получение, подписание и аннулирование. «Доставлен» само по себе не означает, что контрагент подписал документ.

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

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

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

Правила работы ИИ-агентов отделяют разработку от действий с рабочими документами. Для написания обмена подойдут тестовый ящик и синтетические файлы. Как отделять данные клиентов от кода, разобрано в соседней статье.

Быстрый старт Диадока использует тестовую подпись. Успех такого примера не проверяет полномочия на боевое подписание. Сотрудник заказчика согласует этот сценарий отдельно от чтения статусов.

Наш опыт здесь относится к разработке сайта, а не к внедрению Диадока у клиента. Инженер ведёт машину агентов на vibecoding.ru. Её ошибки показывают, какие проверки нельзя заменить успешной загрузкой файла.

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

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

Первый объём удобно ограничить входящими документами выбранного ящика. Заказчик задаёт правило привязки и перечень нужных статусов. Инженер разбивает обмен на задачи в его репозитории.

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

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

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

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

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

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

Для разового обмена с закрытым составом работ стоит сравнить отдельную смету. Подписка подходит, когда после первого запуска нужно добавлять типы документов и менять систему заказов. Формат оплаты выбирают по этому продолжению работы.

Готовность команды к такой работе можно оценить через страницу для руководителя. До начала разработки понадобится перечень документов и человек заказчика, который принимает правила привязки и статусов.

1. Свяжите каждый документ с заказом по идентификаторам и ящику, а не только по номеру на печатной форме.

2. Показывайте статус вместе со временем проверки и видимой остановкой обновления.

3. Принимайте обмен после прерывания и повтора без дублей, а не после первой загрузки файла.

4. Отдавайте агентам разработку технического обмена; подписание согласуйте отдельным действием.

5. Согласуйте состав приёмки и расходы сервисов отдельно от цены месяца разработки.