Интеграция перестала работать: восстанавливают передачу и сверяют пропущенные события

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

Проверяют путь до записи в CRM. Отправитель мог собрать пакет, приёмник мог его принять, а обработчик мог отклонить поле или не записать результат.

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

После исправления проводят контрольное событие через весь путь. Видят запись и нужные поля в CRM, а не только сообщение «отправлено» в журнале сайта.

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

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

Сначала определяют окно сбоя по последнему подтверждённому результату и восстановлению. Список берут из источника, затем ищут соответствующие записи в приёмнике.

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

Приём события через webhook проверяют по отправителю, содержанию и повторной доставке.

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

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

Stripe предупреждает о повторной доставке и негарантированном порядке событий. Ручная переотправка не отменяет автоматические повторы. Правила своей системы проверяют отдельно.

Старое событие может вернуть заказ к прежнему статусу. Перед повтором сверяют актуальное состояние. Историю обмена и действие над заказом нельзя считать одним и тем же.

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

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

Критерий готовности записывают заранее. Такая задача для агента заканчивается записями в обеих системах и списком исключений, а не фразой «ошибка исчезла».

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

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

Проверку сигнала включают в приёмку. В правилах для ИИ-агентов закрепляют её вместе с тестом на отказ: запись «следить за интеграцией» сама ничего не проверяет.

Ремонт собственной интеграции с кодом и сверку пропусков можно обсуждать как задачу разработки. Переключатель в настройках CRM и падение чужого облака требуют другой оценки.

На 8 октября 2026 подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц. Это цена потока работ по продукту, а не установленная стоимость этой починки.

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

1. Найдите обрыв по конкретной заявке и проверьте результат в приёмнике.
2. Разделите починку новых событий и сверку пропусков за время сбоя.
3. Перед повтором исключите дубли и проверьте актуальные статусы.
4. Сохраните список исключений и проверьте, кому придёт сигнал следующего сбоя.