Skip to main content
Вебхуки — рекомендуемый способ получения результатов монитора. Когда монитор срабатывает, Pubrio отправляет POST-запрос с JSON payload на ваш настроенный URL — в реальном времени.

Предварительные требования

  • Ключ API Pubrio с доступом к мониторам
  • Публично доступный HTTPS-эндпоинт (или тестовый URL с usewebhook.com)
Быстрое тестирование: используйте usewebhook.com, чтобы сгенерировать бесплатный временный URL вебхука. Вы можете просматривать каждый входящий payload без развёртывания чего-либо.

Шаг 1: создайте монитор с назначением-вебхуком

Ответ:
Объект headers добавляет пользовательские HTTP-заголовки к каждой доставке (полезно для аутентификации). Объект body добавляет пользовательские поля в корень payload’а вебхука.
Сохраните signature из ответа — она понадобится вам для верификации входящих payload’ов. Она возвращается только при создании, через эндпоинт Signature Reveal, либо из Monitor Lookup с is_signature_reveal: true.

Шаг 2: проверьте подключение вебхука

Используйте эндпоинт Validate Webhook, чтобы протестировать доступность вашего эндпоинта. Он отправляет тестовый payload с данными-заглушками — кредиты не расходуются, реальные сигналы не запрашиваются.
Успешный ответ возвращает отправленный тестовый payload запроса и ответ, который вернул ваш эндпоинт — так вы можете подтвердить, что соединение работает, прежде чем выходить в продакшн.

Шаг 3: протестируйте на реальных данных

После проверки соединения запустите реальный прогон с помощью эндпоинта Process Try. Он получает реальные сигналы и доставляет их на ваш вебхук — используйте tried_at с недавней прошедшей датой, чтобы обеспечить доступность данных:
В отличие от validate, эндпоинт try выполняет реальное сканирование и расходует кредиты. Используйте его, чтобы убедиться, что реальные payload’ы приходят корректно, и получить быструю оценку результатов до запуска планового сканирования.

Шаг 4: верифицируйте подписи

У каждого монитора есть уникальная подпись для верификации того, что входящие payload’ы действительно от Pubrio.
Каждая доставка несёт два заголовка: x-pubrio-signature (секрет, полученный выше) и x-pubrio-signature-256 (hex HMAC-SHA256 сырого тела запроса с этим секретом в качестве ключа). Проверяйте HMAC по полученным байтам до разбора JSON.

Структура payload’а вебхука

Payload’ы отличаются в зависимости от detection_mode монитора:
В режиме signal_first payload содержит массив signals верхнего уровня:
Каждая запись сигнала содержит детали сигнала и связанные обогащённые компании и людей.
Пользовательские поля body из destination_config появляются в корне payload’а (например, "pipeline": "my-webhook", если это настроено в вашем назначении).

Сигналы экспансии

Наряду с jobs, news и advertisements, монитор может отслеживать сигналы экспансии — датированные доказательства того, что компания выходит на новый рынок или растёт на нём. Добавьте expansions в signal_types:
Фильтры экспансии используют словарь Expansion Search, а не словарь вакансий/новостей/рекламы — froms и tos для коридора, плюс stages, scopes, momentum, freshness, signal_types, signal_subtypes, signal_strengths, source_types и window_days. Разрешите допустимые slug из Expansion Reference.
Вебхук доставляет сигналы экспансии в единице записи монитора. При единице signal по умолчанию (signal_first) каждая запись — один сырой сигнал (HIRE, AD, OFFICE…), чей companies[0] несёт карточку (компания, рынок); country_code — это рынок. Задайте record_unit: "company", чтобы получать одну запись на компанию с вложенными сигналами. Email-дайджест всегда группирует по компании и рынку.

Облачный след

DNS — сигнал облачного следа: компания разворачивает облачную или хостинговую инфраструктуру на рынке. Сузьте монитор расширения через signal_types внутри фильтров:
Каждая доставка содержит evidence_url — страницу Pubrio, подтверждающую сигнал. Сырые данные об инфраструктуре в полезную нагрузку не попадают. Чтобы получать те же хосты как чистый поток событий с фильтрами по провайдеру, региону и городу, используйте отдельный тип сигнала cloud_footprints ниже.

Payload сигнала экспансии

Значения по каждому полю приведены в Expansion Field Reference. Чтобы получать те же строки по запросу, а не по триггеру, используйте Expansion Signal Search.

Сигналы облачного следа

Добавьте cloud_footprints в signal_types, чтобы получать по записи на каждый хост, который компания разворачивает на рынке за пределами своей страны: новый сервер у облачного или хостинг-провайдера либо сервер, сменивший регион или страну. Это та же инфраструктурная улика, что читает сигнал экспансии DNS, но доставляется как чистый поток событий, а не как этап рынка: каждый хост в порядке поступления, с собственными фильтрами следа, без этапов, оценок и окон.
Каждый signal содержит provider, cloud_region, city, novelty, country_code, country_name, event_date, локализованный display_label вроде AWS · Frankfurt и evidence_url. Сырые имена хостов и IP-адреса никогда не включаются. Инфраструктура домашнего рынка в этот поток не входит.

Правила доставки

Что такое одна запись

Запись — это то, что считают лимиты, и одна позиция доставки. По умолчанию она следует режиму обнаружения: signal_first доставляет сигналы (одна позиция signals[] на вакансию, объявление, статью или сигнал экспансии), company_first доставляет компании (одна позиция companies[] на компанию с вложенными сигналами). Задайте record_unit, чтобы выбрать явно: например, record_unit: "company" на мониторе объявлений signal_first даёт одну позицию на рекламодателя вместо одной на объявление.

Исключение компаний

excluded_companies (а также excluded_domains и excluded_linkedin_urls, разрешаемые так же, как companies) — список «никогда не доставлять»: исключённая компания отбрасывается до обогащения и списания в обоих режимах, а список наблюдения company_first пропускает её, пока она в списке. До 100 000 компаний на монитор — хватает на экспорт существующих клиентов из CRM. В Update Monitor передайте companies_mode или excluded_companies_mode как add / remove, чтобы изменить только отправленные записи, не пересылая весь список.

Лимиты

Список любого размера читается постранично: Company Search с company_groups: [source_group_id] (или excluded_group_id); оба id возвращает Lookup Monitor, который возвращает и полные списки.

Сначала самое новое

По умолчанию монитор доставляет записи в порядке поступления, сначала самые старые, а лимит переносит остаток, поэтому накопившееся за день обрабатывается раньше новых сигналов. is_newest_first: true меняет это: каждый запуск доставляет самые свежие подходящие записи, а то, что не вошло в лимит, пропускается навсегда и не ставится в очередь. Это действует для всех типов сигналов и для монитора, который возобновляет работу после паузы или исчерпанного дневного бюджета.

Дедупликация и повторная доставка

  • Сигнал никогда не доставляется дважды. Каждая успешная доставка записывает ключи своих сигналов, и каждый запуск отбрасывает кандидатов, уже имеющихся в журнале, для всех типов сигналов. Вакансии, новости и объявления также хранят курсор по типу, так что доставленный сигнал даже не выбирается снова.
  • company_dedupe_days: N гарантирует, что компания появится не более чем в одной доставке за N дней по всем типам сигналов монитора; её последующие сигналы внутри окна пропускаются.
  • Каждый payload содержит metadata.monitor_log_id (строка Журнала статистики для этой попытки) и metadata.parent_monitor_log_id (null при первой попытке; при повторе, автоматическом или через Повтор обработки, id первой попытки). Те же сигналы могут прийти снова только через такой повтор, поэтому дедуплицируйте по parent_monitor_log_id || monitor_log_id. Повтор по умолчанию отправляет payload первой попытки как есть; передайте is_use_original_payload: false, чтобы сначала заново применить текущие правила (исключения и оба журнала), и тогда повтор, в котором ничего не осталось, пропускается с кодом 40085.

Назначение по email

Для команд, предпочитающих доставку по email, установите destination_type в "email":
Pubrio поддерживает доставку email под white-label для агентств и команд. Свяжитесь с нами, чтобы узнать о настройке домена отправителя и брендинга.

Устранение неполадок

  • Убедитесь, что ваш эндпоинт публично доступен (не за файрволом или VPN)
  • Убедитесь, что он возвращает код статуса 200 — остальные коды считаются сбоями
  • Используйте эндпоинт Validate Webhook, чтобы проверить связность
  • Проверьте Statistic Logs на предмет сообщений об ошибках и кодов ответа
Если ваш вебхук постоянно возвращает коды, отличные от 200, монитор приостанавливается после достижения max_failure_trigger последовательных сбоев. Устраните проблему и реактивируйте через Update Monitor.
Если доставка завершается ошибкой и настроены повторные попытки, вы можете получить один и тот же payload несколько раз. Используйте triggered_at или ID журнала, чтобы дедуплицировать на своей стороне.
Уменьшите max_records_per_trigger, чтобы ограничить количество записей на доставку. Вы также можете сузить фильтры, чтобы уменьшить объём совпадающих сигналов.
Последнее изменение 8 октября 2026 г.