Skip to main content

​
Frequência em tempo real

O parâmetro frequency_minute controla a frequência de varredura do seu monitor.
Com frequency_minute: 0, a Pubrio detecta e entrega sinais assim que aparecem — sem polling, sem atraso.

​
Configuração de retentativas

Quando uma entrega de webhook falha, as retentativas ajudam a recuperar automaticamente.
As retentativas reentregam o mesmo payload — elas não executam novamente a detecção do sinal nem consomem créditos de busca adicionais.

​
Reprocessar entrega

O endpoint Process Retry permite reprocessar uma entrega específica que falhou. Principais benefícios:
  • Sem cobrança por falhas — você não é cobrado em créditos quando uma entrega falha. Créditos só são consumidos em uma entrega bem-sucedida.
  • Solução de problemas — reprocesse uma entrada de log com falha para diagnosticar problemas de webhook sem criar novos triggers.
  • Opção de destino original — use is_use_original_destination para reprocessar com o snapshot de destino do log original, útil quando você atualizou sua URL de webhook desde a falha.
Encontre entregas com falha via Statistic Logs e reprocesse-as individualmente.

​
Tratamento de falhas

O parâmetro max_failure_trigger (intervalo: 1-10, padrão: 5) controla quantas falhas de entrega consecutivas são permitidas antes que o monitor seja pausado automaticamente. Abordagem recomendada:
  1. Defina notification_email para receber alertas quando ocorrerem falhas
  2. Mantenha max_failure_trigger entre 3-5 para monitores em produção
  3. Use Statistic Logs para diagnosticar falhas — verifique error_message e response_status_code
  4. Após corrigir o problema, reative via Update Monitor
  5. Use Process Retry para reprocessar entregas específicas que falharam

​
Polling com endpoints de estatísticas

Enquanto os webhooks cuidam da entrega em tempo real, os endpoints de estatísticas oferecem capacidades de monitoramento, depuração e auditoria.

​
Polling de visão geral

Use Monitor Statistics para uma verificação de integridade em nível de dashboard:
Retorna métricas agregadas: total de monitores, triggers hoje vs. ontem, taxas de sucesso e taxas de comparação.

​
Polling baseado em log

Use Statistic Logs para revisar o histórico de triggers:
Cada entrada de log inclui status, uso de créditos, contagens de sinais/empresas/pessoas, tempo de processamento e detalhes de erro.
Combine a entrega via webhook com o polling periódico de logs para máxima confiabilidade: os webhooks lidam com o processamento em tempo real, enquanto o polling de logs captura qualquer entrega perdida e fornece uma trilha de auditoria.

​
Recomendações de escala

Prefira monitores focados em vez de excessivamente amplos. Um monitor rastreando “vagas de IA em empresas enterprise dos EUA” é mais fácil de depurar do que “todas as vagas em qualquer lugar”. Monitores focados também permitem rotear diferentes tipos de sinal para diferentes endpoints de webhook.
Seu endpoint de webhook deve:
  • Responder em até 30 segundos
  • Retornar 200 imediatamente e processar os dados de forma assíncrona
  • Lidar com payloads duplicados de forma adequada (idempotência)
  • Registrar todos os payloads recebidos para depuração
Use Get Monitor List com filtros:
  • Filtre por detection_mode e destination_type
  • Ordene por last_modified ou last_trigger_at
  • Pesquise por nome com search_term
Use Monitor Statistics para identificar rapidamente monitores com baixo desempenho.