CRM • аналитика • автоматизация продаж • собственные виджеты
Услуги →Виджеты →Кейсы →Блог →О компании →Контакты →Поддержка →Оставить заявку →

Интеграции

Webhook или опрос API: как выбрать способ синхронизации

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

Редакция Balance••3 мин на чтение

Для оперативной синхронизации удобно получать уведомления об изменениях, а для поиска пропусков — периодически сверять данные через API. Выбор между webhook и опросом начинается с допустимой задержки и требований к восстановлению. Сам способ передачи ещё не обеспечивает доставку без потерь: это свойство всей цепочки от источника до подтверждённой записи в CRM.

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

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

Укажите также допустимую длительность недоступности. Если принимающая сторона не работает несколько часов, источник должен сохранять события либо позволять восстановить изменения за этот интервал. Без такого условия обещание «синхронизации в реальном времени» мало что объясняет заказчику.

Что проверять у webhook

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

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

Где полезен опрос API

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

Граница между соседними выборками должна учитывать одинаковые временные метки и запоздалые записи. Небольшое перекрытие интервалов вместе с защитой от повторов обычно надёжнее строгого запроса «всё после последней секунды». Конкретное перекрытие выбирают по наблюдаемым задержкам, а не случайной константе.

Условный пример: заявки и реквизиты

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

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

Как сравнить стоимость сопровождения

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

Отдельно согласуйте работу с удалением. Отсутствие карточки в очередной выборке не всегда доказывает удаление: могли измениться права или фильтр. Бизнес-правило удаления и доступные признаки проверяют отдельно от обновлений. Общий контекст договорённостей раскрыт в статье об интеграции CRM и 1С.

Приёмка выбранной схемы

Проверьте четыре сценария:

  • Повтор сообщения после успешной обработки.
  • Временную недоступность CRM при сохранённой очереди.
  • Изменение объекта во время обхода API.
  • Восстановление после перезапуска обработчика.

У каждого события должен находиться итог: доставлено, ожидает обработки либо требует разбора.

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

Применить в вашей компании

Обсудим вашу задачу?

Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.