Как не терять заявки при интеграции CRM: вебхуки, очереди и защита от дублей

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

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

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

Почему схема «форма → вебхук → CRM» ненадёжна

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

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

Ещё одна ловушка: HTTP 200 означает, что получатель подтвердил запрос. Он не доказывает, что лид успешно создан в CRM, если система отправила ответ до надёжного сохранения события. Обратная ситуация тоже возможна: CRM уже создала сделку, но отправитель не получил ответ и повторил запрос. Тогда без защиты появляется дубль.

Надёжная архитектура: пять отдельных этапов

Для критичных заявок полезно разделить приём события и его обработку. Базовая схема выглядит так:

1. Источник события — сайт, магазин, форма, платёжный сервис или телефония.
2. HTTPS-приёмник — проверяет подлинность запроса, формат и размер сообщения.
3. Журнал входящих событий (inbox) — надёжно сохраняет событие и его уникальный идентификатор в базе.
4. Очередь и обработчик — выполняют работу в фоне, при необходимости повторяют запрос к CRM.
5. CRM и сверка — создают или обновляют сущности, а отдельная задача проверяет расхождения.

Важно соблюдать порядок: сначала сохранить событие в устойчивое хранилище, затем подтвердить приём. Если обработка вынесена в очередь, подтверждать HTTP 2xx стоит после успешного сохранения, а не просто после получения JSON в память. Очередь, журнал и CRM должны иметь понятные правила восстановления при сбоях.

1. Проверяйте отправителя, а не только адрес запроса

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

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

2. Делайте операции идемпотентными

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

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

Нельзя автоматически считать дублями заявки с одинаковым номером телефона: один клиент может сознательно оставить несколько разных обращений. Идентификатор доставки, идентификатор бизнес-события и идентификатор клиента — разные понятия. Документация Shopify различает идентификатор доставки и идентификатор исходного события.

3. Выносите тяжёлую работу из HTTP-обработчика

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

Более устойчивый вариант: обработчик быстро проверяет запрос, записывает событие в inbox и возвращает успех. Отдельный воркер берёт событие, вызывает API CRM, фиксирует результат и только после этого отмечает задачу выполненной. При перезапуске сервиса незавершённые события остаются доступными для обработки.

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

4. Настраивайте повторы и очередь ошибок

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

Полезно хранить число попыток, время следующего запуска, последнюю ошибку и корреляционный идентификатор. После исчерпания лимита событие переносится в очередь ошибок — dead-letter queue — и становится видимым ответственному специалисту.

Поведение конкретного поставщика нельзя угадывать. Microsoft описывает, какие HTTP-коды считаются успешными для Azure Event Grid и как устроены повторные доставки. Для другой CRM или сервиса эти правила могут отличаться: проверяйте их официальную документацию.

5. Сверяйте данные даже после успешной доставки

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

Поэтому для важных процессов нужна периодическая сверка: система запрашивает список заказов или обращений у источника за заданный период, сопоставляет его с CRM и повторно ставит недостающие операции в очередь. Shopify рекомендует reconciliation jobs — фоновые задачи, которые помогают восстановить согласованность данных.

Что делать, если события приходят не по порядку

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

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

Какие показатели контролировать руководителю

Не обязательно читать серверные логи. Нужна понятная панель с операционными метриками:

• количество принятых событий и созданных в CRM сущностей;
• доля ошибок приёма и обработки, число повторных попыток;
• возраст самой старой необработанной заявки;
• число сообщений в очереди ошибок и время их восстановления;
• расхождения между источником заявок и CRM после сверки;
• среднее и предельное время от отправки формы до появления обращения у менеджера.

Порог тревоги устанавливают под реальный процесс. Для горячих лидов задержка в несколько минут может быть критичной, а для ночной синхронизации каталога — допустимой. Универсального «правильного» числа нет.

Мини-чек-лист приёмки интеграции

Перед запуском попросите подрядчика показать не только успешный сценарий, но и испытания отказов:

1. Дважды отправить одно событие и убедиться, что бизнес-операция выполнена один раз.
2. Одновременно отправить два одинаковых запроса и проверить защиту от гонки.
3. Отключить CRM на несколько минут, затем восстановить и убедиться, что события дошли.
4. Отправить сообщение с неверной подписью и убедиться, что оно отклонено.
5. Проверить просроченное или неверно сформированное событие и очередь ошибок.
6. Отправить обновления в обратном порядке и проверить итоговый статус.
7. Имитировать длительный простой и запустить сверку с источником.
8. Проверить, что в журналах нет токенов, паролей и лишних персональных данных.

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

Когда нужна доработка существующей интеграции

Если менеджеры регулярно вручную ищут потерянные обращения, удаляют дубли или не понимают, почему статус заказа изменился обратно, проблема часто находится между системами, а не в интерфейсе CRM.

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

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

Практический вывод: цель интеграции — не отправить запрос, а гарантированно довести бизнес-событие до контролируемого состояния. AVEXIUM помогает проектировать и дорабатывать CRM-интеграции, включая очереди, мониторинг, защиту от дублей и восстановление после сбоев. Начните с карты источников заявок и списка ситуаций, в которых данные сегодня теряются.