Поставщик изменил остаток в 10:03. Ваш магазин узнает об этом при следующем обращении к API или после входящего уведомления об изменении. Оба способа могут быть полезны. Выбор зависит от того, что умеет источник, какую задержку допускает бизнес и как вы будете замечать пропущенные обновления.
Вебхук часто представляют как замену расписанию. Для реальной интеграции полезнее другой вопрос: каким способом получить сигнал об изменении и каким способом проверить итоговое состояние. Иногда это два разных механизма.
В чём различие для владельца процесса
При опросе API ваша система сама запрашивает сведения: например, изменившиеся за выбранный период позиции. При вебхуке источник отправляет сообщение в настроенный вами обработчик. Состав такого сообщения определяет поставщик: внутри может быть вся запись, её идентификатор или только уведомление о событии.
Не стоит предполагать наличие вебхуков у любого API. В спецификации OpenAPI предусмотрено описание обратных HTTP-вызовов, но поддержка таких вызовов в конкретном сервисе должна быть подтверждена его документацией.
Для покупателя разница проявляется не в технологии, а в ответе на вопрос «насколько свежие сведения я вижу». Если магазин допускает обновление справочника раз в день, постоянный поток событий может оказаться избыточным. Если наличие влияет на подтверждение заказа, задержку нужно обсуждать отдельно от обновления описаний товаров.
Учебный пример: остатки и характеристики
Представим магазин комплектующих. Поставщик предлагает API каталога и уведомления об изменении наличия. Описание товара меняется редко, а количество на складе важно в течение дня. Для такой задачи можно рассмотреть раздельную схему.
| Данные | Возможный способ получения | Что проверять |
|---|---|---|
| Описания и характеристики | Плановая загрузка каталога | Полноту набора и устойчивые идентификаторы |
| Изменение наличия | Уведомление с последующим чтением записи, если это предусмотрено API | Подлинность события и текущее состояние позиции |
| Итоговая сверка | Периодическая контрольная выборка | Пропущенные, повторные и устаревшие обновления |
Это пример проектирования, а не готовый режим каждого магазина. Если API не позволяет читать изменения или получать события, состав процесса будет другим. Также проверьте, разрешает ли тариф источника выбранную частоту обращений.
Что спросить про вебхуки до подключения
Открыть адрес для входящих сообщений недостаточно. У поставщика стоит выяснить, как подтверждается отправитель, есть ли подпись запроса, повторяет ли он доставку после ошибки и какой ответ считает успешным. Если подпись предусмотрена, проверяйте её по официальному алгоритму поставщика. Самостоятельно придумывать замену его протоколу не стоит.
Отдельные вопросы касаются порядка и повторов. Может ли одно событие прийти повторно? Содержит ли оно уникальный идентификатор? Возможно ли получить более раннее изменение после более позднего? Общего ответа для всех вебхуков нет, поэтому правила обработки нельзя строить только на названии технологии.
Сохраните согласованные ответы рядом с настройкой интеграции. Через полгода причина повторной записи цены будет понятнее по этому договору, чем по воспоминанию «там вроде всё приходило автоматически».
Когда опрос API проще и надёжнее для вашей задачи
Расписание удобно, когда источник не отправляет события, обновления нужны в определённое время или достаточно получать целую подтверждённую выборку. У такого решения есть понятная цена: между запросами существует задержка, а каждое обращение расходует доступную квоту источника.
Перед сокращением интервала посчитайте количество обращений. Важно учитывать не только один запрос на запуск, но и страницы каталога, отдельные карточки и повторы после временных ошибок. Это расчёт вашей схемы, а не характеристика опроса как такового.
Если API поддерживает выборку изменений, проверьте её границы. Что означает время в фильтре? Включается ли запись ровно на границе? Как обрабатывается смена часового пояса? Можно ли повторить перекрывающийся участок без дублирования? Такой разбор обычно полезнее, чем спор о том, какой способ современнее.
Как не превратить быстрый сигнал в неверную запись
Пусть уведомление сообщает, что цена позиции изменилась. Прежде чем обновлять CRM, найдите товар по согласованному ключу, проверьте источник, валюту и нужную версию данных. Если уведомление содержит только идентификатор, нельзя считать его полноценным прайсом.
Для ответственных обновлений предусмотрите место, где видно принятое событие, результат обработки и причину отказа. Повторное сообщение должно обрабатываться по заранее выбранному правилу. Отсутствующее событие должно обнаруживаться контрольной сверкой, если она нужна вашему процессу.
В Akmelo подготовленные данные JSON-выгрузки можно отправлять настроенному HTTP-обработчику через исходящий вебхук. Это способ доставки результата из платформы, а не универсальное подключение к любому отправителю событий. Состав входящих сообщений источника, обработка получателем и связь с конкретной CRM требуют отдельной настройки и проверки.
Начните с одного вида данных и зафиксируйте допустимое время устаревания. Затем выберите способ получения и способ сверки. После этого будет понятно, действительно ли нужны события, достаточно ли расписания или стоит соединить оба подхода.
