Бронирование не появилось в CRM, одна заявка создалась дважды, напоминание об оплате ушло после поступления денег: причиной таких ситуаций может быть автоматизация, не рассчитанная на сбои. В 2026 году недостаточно просто соединить WordPress, сервис бронирования и систему управления бизнесом. Для небольшой компании в Ницце или Каннах важен и другой вопрос: что произойдёт, если соединение перестанет работать?

Вебхук: уведомление от одной системы другой

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

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

Подтвердить получение и сохранить задачу

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

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

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

Не допустить создания дубля при повторном уведомлении

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

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

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

Учесть задержки и восстановить недостающие данные

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

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

Что проверить перед запуском

Проверьте не только успешную передачу, но и сбой с последующим восстановлением:

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

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

Выбрать уровень надёжности под задачи бизнеса

У независимого специалиста в Монако и компании, работающей с бронированиями в Приморских Альпах, разные требования. Начните с процесса, сбой которого обходится дороже всего. NIKAIA.NET поможет спроектировать интеграции PHP, WordPress и CRM с понятными правилами восстановления и возможностью замечать ошибки.

Что проверить перед публикацией

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