Как обнаружить пропущенный вебхук и восстановить данные

Покупка есть в магазине, но в CRM её нет. Разработчик источника показывает успешную отправку webhook, а интегратор — отсутствие ошибки на сервере. Оба могут быть правы: сообщение приняли на входе, но не обработали дальше.

Webhook, или вебхук, — уведомление, которое одна система отправляет другой по факту события. Оно обычно содержит данные или ссылку на изменившийся объект. Успешный ответ точки приёма подтверждает определённый этап передачи; окончательный смысл такого ответа задаёт реализация.

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

Нарисуйте путь одного события

Минимальная цепочка: источник создал событие, попытался передать, получатель проверил запрос, надёжно сохранил запись, обработал её и обновил нужное состояние. На каждом этапе сохраняются ID события и результат.

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

Stripe рекомендует быстро отвечать на вебхуки, обрабатывать их асинхронно, проверять подпись и учитывать дубли. Документация также описывает ограниченный период повторных попыток. Это свойства конкретной интеграции: у другого отправителя условия нужно выяснить отдельно. [1]

Узнайте гарантии отправителя

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

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

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

Отличите виды пропусков

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

Восстанавливайте данные без повторных действий

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

Отдельно учитывайте состояние бизнес-действия. Если сервер отправил SMS и потерял ответ провайдера, автоматический повтор способен создать вторую SMS. Нужны ключ операции, журнал результата и, если доступно, проверка статуса у провайдера.

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

Условный пример ежедневной сверки

В системе заказов за выбранный период 1 000 подходящих операций. В CRM найдены 970 уникальных ID этих операций. Из 30 расхождений двадцать ещё находятся в допустимой очереди, пять отклонены из-за отсутствующего customer ID, пять вообще не имеют подтверждения приёма.

Нельзя повторно отправить все тридцать как «потерянные» без разбора. Для ожидающих проверяют срок обработки, для отклонённых исправляют причину и сохраняют исходный ID, для отсутствующих инициируют восстановление у источника.

После повторов проверяют не только равенство числа 1 000, но и совпадение состава ID и важных полей. Лишние записи могут скрыть недостающие, если смотреть лишь на итоговый счётчик.

Назначьте срок и порядок восстановления ошибок

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

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

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

Снизьте риск потери между покупкой и уведомлением

Есть отдельная проблема: заказ записался в базе, а создание уведомления не состоялось. Паттерн transactional outbox предлагает сохранять бизнес-изменение и запись для последующей отправки в одной транзакции. AWS описывает этот способ устранить разрыв двух независимых записей, сохраняя необходимость обработки дублей. [2]

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

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

Источники

[1] Stripe. Receive Stripe events in your webhook endpoint. Техническая документация. Разделы Event ordering, Handle duplicate events, Automatic retries и Handle events asynchronously. Проверено 22.09.2026.

[2] Amazon Web Services. Transactional outbox pattern. AWS Prescriptive Guidance. Разделы Intent и Issues and considerations. Проверено 22.09.2026.