Skip to main content
POST
Validar webhook de monitor

Autorizaciones

pubrio-api-key
string
header
requerido

Un token de API único que representa las acciones que realizas a través de la API, junto con los permisos y operaciones correspondientes. Puedes crearlo en la sección Configuración.

Cuerpo

application/json
destination_config
object
requerido

Configuración del destino. Para webhook: requiere webhook_url (string), y opcionalmente headers (object) y body (object). Para email: acepta email (string) o emails (array de strings). Para sequences: requiere sequence_identifier (string) además de al menos uno de is_people_search_enrolled / is_company_contact_enrolled establecido en true.

Ejemplo:
monitor_id
string<uuid>

Identificador único de un monitor existente que se va a probar. Opcional para probar configuraciones nuevas.

name
string

Nombre del monitor.

description
string

Descripción del monitor.

detection_mode
enum<string>

Cómo se detectan las señales. signal_first escanea el mercado de forma amplia; company_first da seguimiento a una lista de cuentas específicas y requiere al menos una empresa, dominio o URL de LinkedIn. Inmutable después de la creación — cambiarlo en un monitor existente devuelve 40021. Crea un monitor nuevo en su lugar.

Opciones disponibles:
company_first,
signal_first
signal_types
enum<string>[]

Tipos de señales que se van a monitorear.

Opciones disponibles:
jobs,
news,
advertisements,
expansions
signal_filters
object[]

Una entrada por cada flujo de señales que observa el monitor.

Ejemplo:
company_filters
object

Filtros globales de empresa. Acepta los mismos parámetros que el endpoint Company Search.

Ejemplo:
companies
string<uuid>[]

Lista de UUID de domain_search_id de empresa. Alternativa: usa domains o linkedin_urls.

domains
string[]

Lista de dominios de empresa. Alternativa a companies.

linkedin_urls
string<uri>[]

Lista de URL de LinkedIn de empresas. Alternativa a companies.

is_company_enrichment
boolean

Indica si se deben enriquecer los datos de empresa.

is_people_enrichment
boolean

Indica si se deben enriquecer los datos de personas.

people_enrichment_configs
object[]

Array de capas de enriquecimiento de personas. Contiene max_people_to_return (1-25), people_contact_types (consulta Redeem) y filters (consulta People Search).

Ejemplo:
destination_type
enum<string>

Tipo de destino de entrega.

Opciones disponibles:
webhook,
email,
sequences
frequency_minute
integer

Frecuencia de activación en minutos. Mín.: 0, Máx.: 10080.

Rango requerido: 0 <= x <= 10080
max_failure_trigger
integer

Número máximo de fallos consecutivos antes de pausar. Mín.: 1, Máx.: 10.

Rango requerido: 1 <= x <= 10
max_daily_trigger
integer

Número máximo de activaciones por día. Mín.: 0, Máx.: 86400.

Rango requerido: 0 <= x <= 86400
max_records_per_trigger
integer

Controla el número máximo de registros entregados por activación. Los valores más bajos reducen el tamaño de la carga útil por entrega, lo cual se recomienda para conjuntos de resultados grandes o integraciones con límite de tasa. Mín.: 1, Máx.: 100, Predeterminado: 25. Consulta Setting up Webhooks para más orientación.

Rango requerido: 1 <= x <= 100
notification_email
string<email>

Correo electrónico para notificaciones de fallo.

max_retry_per_trigger
integer

Número máximo de reintentos por activación. Mín.: 0, Máx.: 3.

Rango requerido: 0 <= x <= 3
retry_delay_second
integer

Retraso entre reintentos en segundos. Mín.: 1, Máx.: 5.

Rango requerido: 1 <= x <= 5

Respuesta

Respuesta correcta que contiene los resultados de la validación del webhook: la configuración del destino y las cargas útiles de solicitud/respuesta de la prueba. Si el webhook falla, el endpoint responde 400 (MONITOR_WEBHOOK_URL_INVALID) con la respuesta del webhook en los detalles del error.

data
object