Webhooks или polling: как получать изменения из внешнего сервиса без лишних запросов
Когда сайт интегрируется с CRM, платёжной системой, службой доставки или другим внешним сервисом, возникает простой вопрос: как узнавать, что данные изменились. Самые распространённые варианты — регулярно опрашивать API или принимать webhook сразу после события.
Оба подхода рабочие, но решают задачу по-разному. Если выбрать механизм без учёта частоты событий, ограничений API и требований к скорости, интеграция либо будет создавать лишнюю нагрузку, либо начнёт получать данные с заметной задержкой.
Как работает polling
Polling — это периодический запрос к внешнему сервису: сайт спрашивает, появились ли новые данные после последней проверки. Такой сценарий легко контролировать со своей стороны и можно запускать по cron.
Минус очевиден: большинство запросов может возвращать ответ «ничего нового». Чем меньше допустимая задержка, тем чаще приходится обращаться к API и тем быстрее расходуются лимиты.
Как работает webhook
Webhook меняет направление обмена. Внешний сервис сам отправляет HTTP-запрос на сайт, когда произошло событие: создан заказ, изменилась оплата, появился новый лид или обновился статус доставки.
Так изменения приходят почти сразу и не требуется постоянно опрашивать API. Но появляется другая задача — endpoint должен быть доступен, защищён и готов корректно обрабатывать повторные уведомления.
Когда webhook обычно удобнее
- события происходят нерегулярно;
- изменения нужно получать быстро;
- API имеет строгие ограничения на количество запросов;
- сервис официально поддерживает подписку на нужные события;
- нет необходимости периодически перечитывать весь набор данных.
Когда polling остаётся хорошим вариантом
Не каждый сервис поддерживает webhooks. Кроме того, polling полезен как контрольный механизм: например, раз в несколько часов можно сверять состояние объектов и восстанавливать данные, если отдельное уведомление потерялось.
Для крупных интеграций часто работает гибридная схема: webhook сообщает, что объект изменился, а сайт затем запрашивает его актуальное состояние по API. Так webhook не обязан содержать все данные, а система получает единый источник истины.
Не обрабатывайте тяжёлую логику прямо в webhook
Webhook желательно принять быстро: проверить подпись, сохранить идентификатор события и поставить задачу в очередь. Если внутри HTTP-запроса запускать большой импорт, генерацию документов и несколько внешних API-запросов, отправитель может не дождаться ответа и повторить уведомление.
Webhook лучше воспринимать как сигнал о событии, а не как место для длинной бизнес-логики.
Что обязательно проверить
- Как сервис подтверждает подлинность webhook.
- Может ли одно событие приходить повторно.
- Какие коды ответа считаются успешными.
- Есть ли повторные попытки доставки при ошибке.
- Как восстановить пропущенные события.
- Где логируются входящие уведомления и результат их обработки.
Общую архитектуру внешних обменов мы разбирали в статье про проектирование API-интеграции без хаоса. Если обмен уже работает нестабильно, полезен материал о диагностике сбоев обмена.
Проектирование и доработка подобных сценариев входит в интеграционные работы и техническую поддержку проектов.