Вебхук WB API сообщает сервису о событии автоматически. Для отчётов это позволяет узнать о завершении генерации без постоянного опроса статуса. Однако уведомление и загруженный в вашу систему отчёт — разные результаты: после приёма события обработка данных ещё должна завершиться.

Кому доступен такой способ интеграции

Официальная документация описывает создание вебхуков для сервисов из Каталога решений для бизнеса. Доступ предусмотрен с Сервисным или Базовым токеном при наличии секрета. Категория токена должна соответствовать категории события. Нельзя обещать продавцу, что любой самостоятельно созданный ключ автоматически открывает эту возможность.

Для события завершения генерации отчёта документация называет категорию «Аналитика». Перед реализацией разработчик сверяет доступный перечень событий со своей задачей. Уведомление об отчёте не заменяет уведомления о заказах и не расширяет права сервиса на другие данные магазина.

Что подготовить на принимающей стороне

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

Адрес доставки после создания не редактируется: для другого URL потребуется новый вебхук. Поэтому сначала согласуйте рабочий адрес, ответственного за его доступность и порядок переноса интеграции. Это особенно полезно, когда тестовая и рабочая версии сервиса размещены отдельно.

Почему обработку отчёта лучше отделить от ответа

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

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

Как проверить рабочую цепочку

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

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