Интеграция кажется простой, пока обе системы работают без задержек. Форма получила данные, сервер отправил запрос, CRM создала запись. В реальной работе случаются тайм-ауты, повторы и временная недоступность. Если эти ситуации не описаны, один клиент появляется дважды или обращение исчезает без сообщения.
Повторная доставка события должна быть ожидаемой ситуацией. У интеграции нужен устойчивый способ узнать уже обработанное обращение.
Опишите движение данных
Укажите источник, получателя и момент передачи. Какие поля обязательны, кто назначается ответственным, откуда берутся страница и UTM? Согласуйте, что происходит с отсутствующим email или изменением телефона. Не отправляйте лишние сведения только потому, что они доступны.
API обычно используется для запроса к системе. Webhook позволяет получить событие от другой системы. В одном рабочем сценарии могут участвовать оба механизма. Название способа не определяет правила надёжности, их всё равно нужно проектировать.
Введите идентификатор операции
Обращение должно иметь свой идентификатор, который сохраняется до передачи. При повторном запросе получатель или ваш обработчик сможет связать попытки с одной операцией. Для внешнего события используйте предусмотренный сервисом идентификатор и согласованный ключ соответствия.
Допустим, CRM приняла заявку, но ответ потерялся в сети. Если при повторе создать новую запись без проверки, появится дубль. Решение зависит от возможностей CRM: поиск по ключу, поддержка идемпотентности или собственный учёт уже выполненных операций.
Проверяйте происхождение уведомления
Webhook-адрес может быть известен постороннему. Проверяйте подлинность способом, который предусмотрен отправителем. Например, в Stripe используется подпись и секрет endpoint. Это пример механизма конкретного сервиса, а не универсальное название заголовка для всех API.
Если требуется проверка подписи по исходному телу запроса, не изменяйте его до проверки. После подтверждения проверяйте допустимые события и связанные данные. Секреты храните на сервере и не выводите в страницу или открытый журнал.
| Ситуация | Что предусмотреть |
|---|---|
| Повтор одного события | Проверка уже обработанного идентификатора |
| Временный сбой получателя | Повтор с контролируемым порядком |
| Неполные данные | Явный статус ошибки и объяснение |
| Поддельный запрос | Проверка происхождения |
| Потерянный ответ | Сверка состояния операции |
Подтверждайте приём осмысленно
Некоторые сервисы требуют быстро вернуть успешный ответ webhook. Для сложной работы удобно отдельно надёжно сохранить событие, затем обработать его в очереди. Но подтверждение до сохранения может превратить сбой обработчика в потерянную операцию.
Правила повторов, успешных ответов и времени ожидания берите из документации конкретного отправителя. Не переносите параметры одного провайдера на другой. В журнале полезно видеть этап: принято, сохранено, обработано, требует повторения или вмешательства.
Проверяйте не только удачный запрос
Повторите одно событие, смоделируйте временную ошибку и некорректные данные. Проверьте, что успешная операция не создаёт дубль, а проблемная остаётся обнаруживаемой. Согласуйте возможность повторной обработки после исправления причины.
Для владельца важен понятный итог: где увидеть обращения, которые не передались, кто получает сигнал и как восстановить работу. Без этого подключение может технически существовать, но тихо терять полезные данные.
Документация и проверка сведений
Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.
Материалы по соседним задачам
Коротко о важном
Webhook гарантирует однократную доставку?
Так считать не стоит. Конкретный сервис может повторять события. Обработчик должен учитывать его правила и устойчиво распознавать повторы.
Нужно ли сохранять заявку до передачи в CRM?
Для надёжного сценария полезно иметь подтверждённую запись или другое устойчивое состояние, из которого можно восстановить передачу. Реализация зависит от систем.
Можно проверять webhook по секретному URL?
Это не всегда достаточный механизм. Используйте предусмотренную провайдером проверку подлинности и не публикуйте секреты.
Разработка и SEO в QuickLanding. Помогаем разобраться в задаче и выбрать подходящий состав работ.
Об эксперте
