Skip to main content
Los webhooks son la forma recomendada de recibir los resultados de un monitor. Cuando un monitor se dispara, Pubrio envía una solicitud POST con un payload JSON a tu URL configurada — en tiempo real.

Requisitos previos

  • Una API key de Pubrio con acceso a monitores
  • Un endpoint HTTPS accesible públicamente (o una URL de prueba de usewebhook.com)
Prueba rápida: Usa usewebhook.com para generar una URL de webhook temporal y gratuita. Puedes inspeccionar cada payload entrante sin desplegar nada.

Paso 1: Crear un Monitor con destino Webhook

Respuesta:
El objeto headers añade encabezados HTTP personalizados a cada entrega (útil para autenticación). El objeto body añade campos personalizados a la raíz del payload del webhook.
Guarda el signature de la respuesta — lo necesitarás para verificar los payloads entrantes. Solo se devuelve en el momento de la creación, a través del endpoint Signature Reveal, o desde Monitor Lookup con is_signature_reveal: true.

Paso 2: Validar tu conexión de Webhook

Usa el endpoint Validate Webhook para probar que tu endpoint es accesible. Esto envía un payload de muestra con datos de marcador de posición — no se consumen créditos, no se obtienen señales reales.
Una respuesta exitosa devuelve el payload de solicitud de muestra que se envió y la respuesta que devolvió tu endpoint — así puedes confirmar que la conexión funciona antes de pasar a producción.

Paso 3: Probar con datos reales

Una vez validada la conexión, dispara una ejecución real usando el endpoint Process Try. Esto obtiene señales reales y las entrega a tu webhook — usa tried_at con una fecha pasada reciente para asegurar que haya datos disponibles:
A diferencia de validate, el endpoint try ejecuta un escaneo real y consume créditos. Úsalo para verificar que los payloads reales llegan correctamente y para obtener una estimación rápida de resultados antes de que se ejecute el escaneo programado.

Paso 4: Verificar firmas

Cada monitor tiene una firma única para verificar que los payloads entrantes provienen genuinamente de Pubrio.
Compara esta firma con monitor.monitor_id en los payloads entrantes para verificar la autenticidad.

Estructura del payload del Webhook

Los payloads difieren según el detection_mode del monitor:
En modo signal_first, el payload contiene un arreglo signals de nivel superior:
Cada entrada de señal contiene los detalles de la señal y las empresas y personas asociadas ya enriquecidas.
Los campos personalizados de body en destination_config aparecen en el nivel raíz del payload (por ejemplo, "pipeline": "my-webhook" cuando se configura en tu destino).

Señales de expansión

Junto con jobs, news y advertisements, un monitor puede vigilar señales de expansión — la evidencia fechada de que una empresa está entrando o creciendo en un nuevo mercado. Añade expansions a signal_types:
Los filtros de expansión usan el vocabulario de Expansion Search, no el de trabajos/noticias/anuncios — froms y tos para el corredor, más stages, scopes, momentum, freshness, signal_types, signal_subtypes, signal_strengths, source_types y window_days. Resuelve los slugs válidos en Expansion Reference.
Las señales de expansión se agrupan por empresa y mercado, no por señal. Una empresa que entra en dos mercados produce dos entradas, cada una con la línea de tiempo de señales propia de ese mercado.

Payload de señal de expansión

El significado de cada campo está en la Referencia de campos de expansión. Para obtener las mismas filas bajo demanda en lugar de en un disparador, usa Expansion Signal Search.

Destino por correo electrónico

Para los equipos que prefieren la entrega por correo electrónico, establece destination_type en "email":
Pubrio soporta entrega de correo electrónico de marca blanca para agencias y equipos. Ponte en contacto para conocer cómo personalizar el dominio del remitente y la marca.

Solución de problemas

  • Verifica que tu endpoint sea accesible públicamente (no esté detrás de un firewall o VPN)
  • Asegúrate de que devuelva un código de estado 200 — otros códigos se tratan como fallos
  • Usa el endpoint Validate Webhook para probar la conectividad
  • Revisa Statistic Logs para ver mensajes de error y códigos de respuesta
Si tu webhook devuelve códigos distintos de 200 de forma consistente, el monitor se pausa al alcanzar max_failure_trigger fallos consecutivos. Corrige el problema y reactívalo mediante Update Monitor.
Si una entrega falla y hay reintentos configurados, puedes recibir el mismo payload varias veces. Usa triggered_at o el ID del log para deduplicar en tu extremo.
Reduce max_records_per_trigger para limitar los registros por entrega. También puedes acotar tus filtros para reducir el volumen de señales coincidentes.