> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Boas práticas e polling

> Otimize a configuração do seu monitor para confiabilidade, desempenho e entrega eficiente.

## Frequência em tempo real

O parâmetro `frequency_minute` controla a frequência de varredura do seu monitor.

| Configuração     | Comportamento                                                            | Caso de uso                                            |
| ---------------- | ------------------------------------------------------------------------ | ------------------------------------------------------ |
| **`0` (padrão)** | **Tempo real** — os sinais são detectados e entregues assim que aparecem | A maioria dos monitores — entrega mais rápida possível |
| `1 - 60`         | Intervalo fixo em minutos                                                | Quando você quer uma cadência previsível               |
| `60 - 1440`      | De hora em hora a diário                                                 | Resumos estilo digest, sinais de menor prioridade      |

<Tip>
  Com `frequency_minute: 0`, a Pubrio detecta e entrega sinais assim que aparecem — sem polling, sem atraso.
</Tip>

***

## Configuração de retentativas

Quando uma entrega de webhook falha, as retentativas ajudam a recuperar automaticamente.

| Parâmetro               | Intervalo | Padrão | Recomendação                                                          |
| ----------------------- | --------- | ------ | --------------------------------------------------------------------- |
| `max_retry_per_trigger` | 0 - 3     | 1      | Defina como 2-3 para monitores críticos                               |
| `retry_delay_second`    | 1 - 5     | 1      | Use 3-5 segundos para permitir que problemas transitórios se resolvam |

<Note>
  As retentativas reentregam o mesmo payload — elas não executam novamente a detecção do sinal nem consomem créditos de busca adicionais.
</Note>

***

## Reprocessar entrega

O endpoint [Process Retry](/pt/api-reference/endpoint/monitors/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](/pt/api-reference/endpoint/monitors/statistics_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](/pt/api-reference/endpoint/monitors/statistics_logs) para diagnosticar falhas — verifique `error_message` e `response_status_code`
4. Após corrigir o problema, reative via [Update Monitor](/pt/api-reference/endpoint/monitors/update)
5. Use [Process Retry](/pt/api-reference/endpoint/monitors/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](/pt/api-reference/endpoint/monitors/statistics) para uma verificação de integridade em nível de dashboard:

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{ "profile_id": 1 }'
  ```
</CodeGroup>

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](/pt/api-reference/endpoint/monitors/statistics_logs) para revisar o histórico de triggers:

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics/logs \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{
      "profile_id": 1,
      "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "page": 1,
      "per_page": 10
    }'
  ```
</CodeGroup>

Cada entrada de log inclui status, uso de créditos, contagens de sinais/empresas/pessoas, tempo de processamento e detalhes de erro.

<Tip>
  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.
</Tip>

***

## Recomendações de escala

<AccordionGroup>
  <Accordion title="Monitores focados vs. filtros amplos">
    **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.
  </Accordion>

  <Accordion title="Confiabilidade do endpoint 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
  </Accordion>

  <Accordion title="Gerenciando muitos monitores">
    Use [Get Monitor List](/pt/api-reference/endpoint/monitors/monitors) 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](/pt/api-reference/endpoint/monitors/statistics) para identificar rapidamente monitores com baixo desempenho.
  </Accordion>
</AccordionGroup>