# Escolher Webhooks, WebSocket ou polling de RPC > Source: https://docs.blockvectra.com/pt-br/guides/webhook-vs-websocket/ Use Webhooks de endereços para entrega em um receptor HTTPS, WebSocket para assinaturas em tempo real suportadas e polling com limites quando o fluxo exigir seu próprio cursor e recuperação. Criar ouvintes de eventos on-chain para desenvolvedores e agentes de IA exige alinhar a arquitetura da aplicação com as capacidades da rede, garantias de entrega, restrições do receptor e custo operacional. ## Matriz de decisão A tabela abaixo compara todos os três mecanismos de integração entre capacidades de rede suportadas, requisitos de infraestrutura, estratégias de recuperação e modelos de cobrança: | Dimensão | Webhooks de endereços | Assinaturas via WebSocket | Polling de RPC com limites | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Mecanismo principal** | Notificação push entregue via HTTPS POST para um endpoint público | Assinatura de fluxo contínuo (pull-stream) sobre conexão TLS persistente (`wss://`) | Consultas em lote ou agendadas via HTTP JSON-RPC iniciadas pelo cliente | | **Disponibilidade de redes** | Todas as 9 redes suportadas declaradas em `GET /v1/push/chains` | Suportado na Robinhood Chain (robinhood\_mainnet e robinhood\_testnet); redes não atendidas têm `ws: false` e retornam HTTP 404 | Todas as 9 redes suportadas via RPC público sem chave ou JSON-RPC autenticado | | **Requisitos do receptor** | URL HTTPS publicamente acessível, certificado TLS válido, resposta 2xx dentro do tempo limite, verificação de assinatura HMAC SHA-256 no corpo bruto | Conexão de cliente TCP/TLS de saída (`wss://`); gerencia batimentos de coração ping/pong e recuo de reconexão | Cliente HTTP sem estado ou worker agendado; armazena o cursor de bloco local | | **Entrega e ordenação** | Entrega de pelo menos uma vez (at-least-once) com recuo exponencial de repetição; o receptor deve deduplicar pelo `id` do evento ou por `ref` + `type` entre assinaturas | Quadros estritamente ordenados em um único socket ativo; notificações descartadas durante desconexões | Respostas determinísticas de consulta para alturas de blocos confirmadas; o cliente dita o ritmo de execução | | **Reorganizações de cadeia** | Notificações de controle emitidas para `chain.reorg`; o receptor descarta eventos substituídos antes de aplicar replays canônicos | Notificações de logs trazem `"removed": true` para logs reorganizados; `newHeads` requer verificação do hash do bloco pai | O cliente rastreia a continuidade da cadeia via `parentHash` entre os ciclos de polling para detectar reorgs | | **Recuperação de falhas** | A janela de retenção do servidor permite replay via `POST /v1/push/subscriptions/{id}/replay`; lacunas anteriores ao bloco de ativação requerem preenchimento retroativo com `eth_getLogs` | Sem fila no servidor; o cliente reconecta e preenche os intervalos perdidos via `eth_getLogs` deduplicados por `(blockHash, transactionHash, logIndex)` | Retoma consultas a partir do `last_synced_block` armazenado; divide partes pelo `max_logs_block_range` da rede (1.000 blocos) | | **Modelo de cobrança** | Taxa diária de endereço por grupo, baseada na maior contagem de endereços enquanto online durante o dia UTC, mais CU para eventos de dados entregues; consulte a [cobrança de Webhook](https://docs.blockvectra.com/en/guides/webhook-push/#billing-and-example) | Handshake e batimentos de coração não são cobrados; chamadas a `eth_subscribe` / `eth_unsubscribe` e unidades de notificação de socket descarregadas são cobradas em CU | Medido por requisição em Compute Units: `eth_blockNumber` (1 CU), `eth_call` (15 CU), `eth_getLogs` (30 CU); 10M de CU por $1 | | **Mais indicado para** | Monitoramento de depósitos de usuários, rastreamento de endereços de hot wallet, checkouts de comerciantes, webhooks de eventos assíncronos | `newHeads` em tempo real e `logs` filtrados, bots reativos, interfaces interativas em redes suportadas | Reconciliação em lote, tarefas cron, pipelines de ETL, redes sem suporte a WebSocket (como HyperEVM) | ## Quando escolher Webhooks de endereços Escolha a [API de Webhooks de Blockchain](https://docs.blockvectra.com/en/guides/webhook-push/) quando seu backend operar como um serviço web padrão capaz de receber requisições HTTPS de entrada: * **Grandes listas de endereços**: Monitore depósitos ou saques em milhares de endereços de clientes sem manter sockets persistentes por carteira. * **Receptores serverless ou em contêineres**: Funções serverless (AWS Lambda, Cloudflare Workers) são iniciadas com a chegada de webhooks e não precisam manter conexões ativas contínuas. * **Tentativas automáticas e replay**: Interrupções transitórias no receptor são mitigadas pelo recuo automático de tentativas. Dentro da janela de retenção do servidor, entregas perdidas podem ser reenviadas usando o endpoint de replay. * **Considerações sobre o limite de ativação**: A correspondência começa apenas depois que a alteração da assinatura for aplicada (`applied_from_block`). Eventos ocorridos antes da adição de um endereço ou enquanto a assinatura estava `offline` devem ser consultados pelo histórico de logs de RPC. Revise os [fluxos de verificação de assinatura e replay](https://docs.blockvectra.com/en/guides/webhook-push/#verify-signatures) antes de expor receptores de webhook em produção. ## Quando escolher assinaturas via WebSocket Escolha as [Assinaturas via WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) quando baixa latência for necessária e seu processo puder manter um socket de saída de longa duração: * **Cabeçalhos de blocos em tempo real**: Receba `newHeads` via streaming assim que cada bloco for anexado ao topo da cadeia. * **Filtros de eventos de contrato**: Receba via streaming `logs` de contratos em tempo real que correspondam a um endereço ou a um `topic0` específico. * **Ambientes privados**: Ideal para scripts locais, agentes de CLI ou serviços de backend atrás de NAT ou firewalls que não podem expor uma porta HTTPS pública de entrada. * **Verificação de disponibilidade de rede**: WebSocket é suportado na Robinhood Chain (slug de rede `robinhood_mainnet`, Chain ID 4663 e `robinhood_testnet`). A HyperEVM atualmente não tem suporte a WebSocket (`ws: false`); tentar uma conexão WebSocket com uma rede não atendida retorna HTTP 404 ([`unknown_chain`](https://docs.blockvectra.com/en/errors/#unknown_chain)). * **Disciplina de desconexão**: Notificações via WebSocket não são retidas no servidor durante desconexões. Quando o socket cai, os clientes devem se reconectar com recuo exponencial aleatório e preencher retroativamente os blocos perdidos via `eth_getLogs`. Consulte o [guia de Assinaturas via WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) para obter limites de filtros, limites de conexão (20 por chave, 50 por conta) e exemplos de conexão com viem. ## Quando escolher polling de RPC com limites Escolha o polling de JSON-RPC com limites ao executar workers agendados, pipelines de dados ou operar em redes onde o WebSocket não está disponível: * **Redes sem WebSocket**: A HyperEVM (`hyperevm_mainnet`) oferece atualmente acesso HTTP a JSON-RPC, mas não a WebSocket (`ws: false`). Fazer polling de `eth_blockNumber` e consultar `eth_getLogs` dentro dos intervalos de blocos suportados viabiliza o processamento de eventos na HyperEVM. * **Ritmo de consulta controlado**: O polling permite que desenvolvedores e agentes de IA regulem a frequência de requisições, gerenciem o consumo de Compute Units em relação aos limites de taxa (400 CU/s por chave por padrão em contas gratuitas) e evitem quedas de socket durante tarefas de longa duração. * **Limites de intervalo de blocos**: Consultas autenticadas de `eth_getLogs` são limitadas pelo `max_logs_block_range` da rede (1.000 blocos). Exceder esse limite retorna o código de erro `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/en/errors/#logs_range_too_large)). Divida intervalos mais amplos em partes consecutivas que não excedam 1.000 blocos. Veja o [guia de backfill de logs na HyperEVM](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) e o [guia de intervalo de blocos do eth\_getLogs](https://docs.blockvectra.com/en/guides/getlogs-block-range/) para algoritmos de divisão em partes. Para uma lista completa de verificação de cargas de trabalho e testes rápidos, comece com [Como escolher um provedor de RPC](https://docs.blockvectra.com/en/guides/choose-rpc-provider/). Ao escolher um provedor para polling de baixo volume, [compare provedores quanto à cobrança padrão de RPC e cobertura](https://docs.blockvectra.com/en/guides/quicknode-alternative/). Compare a cobrança por uso com os custos de períodos de teste e assinaturas; os custos de notificação e backfill utilizam métricas diferentes das leituras de RPC. ## Guias de implementação ### WebSocket na Robinhood Chain Para `newHeads` em tempo real ou `logs` filtrados na Robinhood Chain, siga o [guia de Assinaturas via WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) para autenticação e requisições de assinatura. Após uma desconexão, reconecte com recuo, assine novamente e preencha blocos perdidos a partir de um cursor salvo com `eth_getLogs`; deduplique os logs por `(blockHash, transactionHash, logIndex)`. ### Polling com limites na HyperEVM Para a HyperEVM (`hyperevm_mainnet`), siga o [guia de backfill de logs na HyperEVM](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) para polling com limites e recuperação. Faça consultas a partir do cursor salvo em partes dentro de `max_logs_block_range`, persista eventos e progresso juntos após o processamento bem-sucedido e repita intervalos incompletos. Verifique a continuidade da cadeia e examine intervalos sobrepostos para tratar reorgs. ## Próximos passos * [Explore o diretório de conjuntos de dados](https://blockvectra.com/en/data/) para ver todos os conjuntos de dados indexados pela BlockVectra. * [Consulte o plano gratuito e os preços](https://blockvectra.com/en/pricing/#free) para verificar o que sua conta inclui. * [Entre no console](https://console.blockvectra.com/login/?next=%2Fkeys%2F) para criar uma API key.