Webhook — это автоматическое уведомление, которое одна система отправляет другой в момент наступления определённого события. Оно доставляется в виде HTTP-запроса на заранее настроенный URL, поэтому принимающей системе не нужно постоянно спрашивать, не изменилось ли что-нибудь. В управлении фидами именно вебхуки позволяют изменению цены в ERP, новому заказу в интернет-магазине или обновлению остатков в складской системе немедленно оповестить платформу фидов, вместо того чтобы платформа опрашивала источник по таймеру. Они превращают обновление фидов из пакетного задания по расписанию в процесс, управляемый событиями.
Почему это важно для управления фидами
Опрос (polling), то есть регулярная проверка исходной системы на изменения, расходует ресурсы и создаёт задержку: если инструмент для фидов проверяет остатки каждые пятнадцать минут, закончившийся товар может до пятнадцати минут оставаться в показах на торговом канале, прежде чем это обнаружится. Вебхук устраняет эту задержку: исходная система сразу передаёт изменение, поэтому товар, помеченный как отсутствующий в 14:00:03, может быть снят с активных листингов к 14:00:04. Такая мгновенность важнее всего для всего, что зависит от времени: флеш-распродаж, выпусков ограниченных партий или подстройки цен под конкурентов, где даже короткая задержка может означать продажу уже недоступного товара или рекламу уже неактуальной цены. Поскольку вебхуки опираются на ту же механику «запрос — ответ», что и любой другой вызов API, они встраиваются в существующие конвейеры автоматизации фидов без отдельной схемы интеграции.
Как это работает
Настройка вебхука означает регистрацию URL обратного вызова в исходной системе — системе управления складом, CMS, платёжном сервисе — и указание, какие события должны вызывать уведомление. Когда событие происходит, исходная система отправляет HTTP-запрос POST на зарегистрированный URL: детали события передаются в теле запроса, а метаданные, например тип события или подпись для проверки, — в HTTP-заголовках. Принимающая система, обычно платформа фидов, обрабатывает эти данные и обновляет соответствующую информацию о товарах. Поскольку вебхуки срабатывают в реальном времени и часто пачками (представьте, что массовое обновление цен вызывает сразу сотни отдельных событий), большинство систем ставят входящие вызовы вебхуков в очередь и обрабатывают их асинхронно, а не мгновенно и синхронно, чтобы принимающая сторона не перегружалась. Вебхуки — базовый строительный блок более широкой автоматизации рабочих процессов, ведь именно они позволяют действию в совершенно другой системе запустить цепочку последующих обновлений фида, и никому не нужно отслеживать изменения вручную.
Пример
<item>
<g:id>SKU-55810</g:id>
<title>Wireless Charging Pad - Matte Black</title>
<g:availability>out of stock</g:availability>
<custom_label_1>updated_via_webhook</custom_label_1>
<last_event>inventory.zero</last_event>
<last_updated>2026-08-15T14:00:04Z</last_updated>
</item>Здесь last_event отражает данные вебхука складской системы, которые вызвали изменение наличия этого товара, а почти мгновенная отметка времени last_updated — практический результат обновлений, управляемых событиями, вместо пакетного обновления по расписанию.
Связанные понятия
Вебхуки используют ту же структуру запроса, что и любой вызов API, только в обратном направлении: инициатором выступает исходная система, а не платформа фидов. HTTP-заголовки такого запроса передают данные аутентификации и метаданные события, необходимые, чтобы доверять запросу и правильно его маршрутизировать. Связанные в цепочку между системами, вебхуки становятся триггерным уровнем большей части автоматизации рабочих процессов в управлении фидами — именно поэтому одно изменение остатков может каскадом привести к обновлённому листингу, приостановленному объявлению и обновлённой записи в фиде без какого-либо ручного участия.
