Предварительные требования
- Ключ API Pubrio с доступом к мониторам
- Публично доступный HTTPS-эндпоинт (или тестовый URL с usewebhook.com)
Шаг 1: создайте монитор с назначением-вебхуком
headers добавляет пользовательские HTTP-заголовки к каждой доставке (полезно для аутентификации). Объект body добавляет пользовательские поля в корень payload’а вебхука.
Шаг 2: проверьте подключение вебхука
Используйте эндпоинт Validate Webhook, чтобы протестировать доступность вашего эндпоинта. Он отправляет тестовый 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
- Company First
В режиме Каждая запись сигнала содержит детали сигнала и связанные обогащённые компании и людей.
signal_first payload содержит массив signals верхнего уровня:Пользовательские поля
body из destination_config появляются в корне payload’а (например, "pipeline": "my-webhook", если это настроено в вашем назначении).Сигналы экспансии
Наряду сjobs, news и advertisements, монитор может отслеживать сигналы экспансии — датированные доказательства того, что компания выходит на новый рынок или растёт на нём. Добавьте expansions в signal_types:
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 сигнала экспансии
Сигналы облачного следа
Добавьте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 для агентств и команд. Свяжитесь с нами, чтобы узнать о настройке домена отправителя и брендинга.
Устранение неполадок
Вебхук не получает payload'ы
Вебхук не получает payload'ы
- Убедитесь, что ваш эндпоинт публично доступен (не за файрволом или VPN)
- Убедитесь, что он возвращает код статуса
200— остальные коды считаются сбоями - Используйте эндпоинт Validate Webhook, чтобы проверить связность
- Проверьте Statistic Logs на предмет сообщений об ошибках и кодов ответа
Монитор приостановлен после сбоев
Монитор приостановлен после сбоев
Если ваш вебхук постоянно возвращает коды, отличные от 200, монитор приостанавливается после достижения
max_failure_trigger последовательных сбоев. Устраните проблему и реактивируйте через Update Monitor.Дублирующиеся payload'ы
Дублирующиеся payload'ы
Если доставка завершается ошибкой и настроены повторные попытки, вы можете получить один и тот же payload несколько раз. Используйте
triggered_at или ID журнала, чтобы дедуплицировать на своей стороне.Payload слишком большой
Payload слишком большой
Уменьшите
max_records_per_trigger, чтобы ограничить количество записей на доставку. Вы также можете сузить фильтры, чтобы уменьшить объём совпадающих сигналов.
