Skip to main content
Webhooks são a forma recomendada de receber resultados de monitores. Quando um monitor é acionado, a Pubrio envia uma requisição POST com um payload JSON para a sua URL configurada — em tempo real.

Pré-requisitos

  • Uma chave de API Pubrio com acesso a monitores
  • Um endpoint HTTPS publicamente acessível (ou uma URL de teste do usewebhook.com)
Teste rápido: use o usewebhook.com para gerar uma URL de webhook temporária e gratuita. Você pode inspecionar cada payload recebido sem precisar implantar nada.

Etapa 1: Criar um Monitor com Destino de Webhook

Resposta:
O objeto headers adiciona cabeçalhos HTTP personalizados a cada entrega (útil para autenticação). O objeto body adiciona campos personalizados à raiz do payload do webhook.
Salve o signature retornado na resposta — você vai precisar dele para verificar os payloads recebidos. Ele só é retornado no momento da criação, pelo endpoint Signature Reveal, ou pelo Monitor Lookup com is_signature_reveal: true.

Etapa 2: Validar a Conexão do Webhook

Use o endpoint Validate Webhook para testar se o seu endpoint está acessível. Isso envia um payload de amostra com dados fictícios — nenhum crédito é consumido e nenhum sinal real é buscado.
Uma resposta bem-sucedida retorna o payload de amostra que foi enviado e a resposta que o seu endpoint devolveu — assim você confirma que a conexão funciona antes de colocar em produção.

Etapa 3: Testar com Dados Reais

Depois que a conexão for validada, acione uma execução real usando o endpoint Process Try. Isso busca sinais reais e os entrega ao seu webhook — use tried_at com uma data recente no passado para garantir que haja dados disponíveis:
Ao contrário do validate, o endpoint try executa uma varredura real e consome créditos. Use-o para confirmar que os payloads reais chegam corretamente e para ter uma estimativa rápida dos resultados antes que a varredura agendada seja executada.

Etapa 4: Verificar Assinaturas

Cada monitor tem uma assinatura única para verificar que os payloads recebidos vêm de fato da Pubrio.
Compare essa assinatura com o monitor.monitor_id nos payloads recebidos para verificar a autenticidade.

Estrutura do Payload do Webhook

Os payloads variam de acordo com o detection_mode do monitor:
No modo signal_first, o payload contém um array signals no nível raiz:
Cada entrada de sinal contém os detalhes do sinal e as empresas e pessoas enriquecidas associadas.
Os campos personalizados de body definidos em destination_config aparecem no nível raiz do payload (por exemplo, "pipeline": "my-webhook" quando configurado no seu destino).

Sinais de Expansão

Além de jobs, news e advertisements, um monitor pode observar sinais de expansão — a evidência datada de que uma empresa está entrando ou crescendo em um novo mercado. Adicione expansions a signal_types:
Os filtros de expansão usam o vocabulário do Expansion Search, e não o de vagas/notícias/anúncios — froms e tos para o corredor, além de stages, scopes, momentum, freshness, signal_types, signal_subtypes, signal_strengths, source_types e window_days. Resolva os slugs válidos em Expansion Reference.
Os sinais de expansão são agrupados por empresa e mercado, não por sinal. Uma empresa entrando em dois mercados gera duas entradas, cada uma com sua própria linha do tempo de sinais daquele mercado.

Payload de Sinal de Expansão

O significado de cada campo está detalhado na Expansion Field Reference. Para obter as mesmas linhas sob demanda em vez de por acionamento, use o Expansion Signal Search.

Destino por E-mail

Para equipes que preferem a entrega por e-mail, defina destination_type como "email":
A Pubrio oferece suporte a entrega de e-mail com marca branca para agências e equipes. Entre em contato para saber mais sobre personalização de domínio de envio e identidade visual.

Solução de Problemas

  • Verifique se o seu endpoint é publicamente acessível (não está atrás de um firewall ou VPN)
  • Garanta que ele retorne um código de status 200 — outros códigos são tratados como falhas
  • Use o endpoint Validate Webhook para testar a conectividade
  • Verifique os Statistic Logs em busca de mensagens de erro e códigos de resposta
Se o seu webhook retornar códigos diferentes de 200 de forma consistente, o monitor é pausado ao atingir max_failure_trigger falhas consecutivas. Corrija o problema e reative usando o Update Monitor.
Se uma entrega falhar e houver novas tentativas configuradas, você pode receber o mesmo payload várias vezes. Use triggered_at ou o ID do log para deduplicar do seu lado.
Reduza max_records_per_trigger para limitar os registros por entrega. Você também pode restringir seus filtros para reduzir o volume de sinais correspondentes.