Webhooks vs. polling: como construir integrações de Open Finance que escalam
Comparação entre polling e webhooks em integrações bancárias, boas práticas de idempotência e processamento assíncrono, sincronização incremental e uma arquitetura de referência para Open Finance.
Atualizado em

Quem já integrou dados bancários conhece o dilema. Como saber que uma conexão terminou de sincronizar, que chegaram transações novas ou que o consentimento expirou? A resposta ingênua é consultar a API de tempos em tempos, o chamado polling. A resposta que escala é ouvir webhooks.
Polling: fácil de começar, caro de manter
No polling, sua aplicação pergunta periodicamente se há algo novo. Funciona, mas os problemas aparecem conforme a base cresce:
- Desperdício: a maioria das chamadas volta sem novidade.
- Latência: se você consulta de hora em hora, um dado novo pode esperar até uma hora para aparecer.
- Rate limits: milhares de conexões consultadas com frequência batem nos limites de requisição.
- Estado inconsistente: é fácil perder uma mudança de estado que aconteceu entre duas consultas.
Webhooks: a plataforma avisa você
Com webhooks, a plataforma de dados chama um endpoint seu quando algo acontece: uma conexão criada, atualizada ou com erro, ou dados novos disponíveis. Você reage ao evento e não faz consultas desnecessárias.
Na Malvo, os webhooks são a fonte da verdade sobre o estado de um Item, a conexão entre um usuário e uma instituição. Eventos como item/created e item/updated dizem quando agir.
Por que não confiar só no retorno do widget
No Open Finance, o usuário é redirecionado ao banco para autenticar e confirmar o compartilhamento, como descreve o FAQ do Open Finance Brasil. Ele pode fechar a aba antes de voltar. Por isso o callback de sucesso no navegador é best-effort: ajuda na experiência, mas não serve como registro. O webhook, que vai de servidor para servidor, serve.
Boas práticas para receber webhooks
1. Responda rápido e processe depois
Devolva sucesso assim que receber e validar o evento, e mande o processamento para uma fila. Endpoint lento gera timeout e reentrega.
2. Seja idempotente
Um evento pode chegar mais de uma vez. Use o identificador do evento para que processá-lo duas vezes não gere duplicidade.
3. Não dependa da ordem
Eventos podem chegar fora de ordem. Ao receber um, consulte o estado atual do recurso na API em vez de supor a sequência.
4. Valide a origem
Verifique a autenticidade de cada chamada como manda a documentação do provedor e exponha o endpoint apenas via HTTPS.
5. Monitore e tenha um plano B
Registre as falhas e mantenha uma reconciliação periódica, leve e pouco frequente, para cobrir algum evento perdido. É o único polling que vale manter.
Sincronização incremental
Quando chegar o aviso de dados novos, não baixe o histórico inteiro outra vez. Busque só o que mudou desde a última sincronização e atualize sua base usando chaves estáveis. O custo cai, os limites de requisição são respeitados e o banco continua consistente.
E fora do Brasil?
No Open Banking europeu e britânico, a conectividade AIS (Account Information Service) nem sempre notifica o agregador em tempo real. Nesse fluxo, o scheduler da Malvo consulta sessões e dados e emite os mesmos webhooks depois de persistir o resultado. Para a sua aplicação, o contrato não muda: você continua ouvindo eventos e não precisa implementar polling para cada país.
Arquitetura de referência
- O backend se autentica na API e gera um token de conexão de curta duração.
- O frontend abre o Connect Widget com esse token.
- O usuário autoriza no banco.
- O webhook
item/createdchega ao seu endpoint, e você registra o Item. - Os webhooks seguintes indicam dados disponíveis, e um worker busca contas e transações de forma incremental.
- Uma reconciliação diária verifica os Items sem eventos recentes.
Erros comuns
- Tratar o callback do navegador como confirmação definitiva.
- Processar o webhook de forma síncrona e pesada.
- Não deduplicar eventos.
- Fazer polling agressivo "por garantia" e estourar rate limits.
- Expor credenciais de API no frontend.
Por que isso importa agora
O Open Finance Brasil chegou a 269,06 milhões de consentimentos ativos em 25/09/2026, segundo o dashboard oficial compilado pelo FintechNode. O estudo da Zetta citado pela Folha fala em cerca de 800 instituições participantes. Uma arquitetura de polling que aguenta cem conexões quebra com cem mil, e desenhar orientado a eventos desde o início evita refazer a integração depois.
Polling atrai pela simplicidade. Webhooks, com idempotência, processamento assíncrono e uma reconciliação leve como rede de segurança, são o que mantém a integração rápida, barata e consistente quando a base cresce.
A Malvo entrega webhooks como fonte da verdade no Open Finance Brasil e no Open Banking da Europa e do Reino Unido, com o mesmo contrato de API. Leia a documentação de webhooks da Malvo.
Continue a leitura

Categorização de transações bancárias: como transformar extratos em informação útil
Por que categorizar transações é difícil, como funciona um pipeline em camadas (regras do cliente, estabelecimento, MCC e palavras-chave) e como medir a qualidade da classificação.
Ler artigo →
Fluxo de caixa consolidado multibanco: como saber se o caixa cobre os vencimentos da semana
Como montar um caixa consolidado de todas as contas da empresa com Open Finance, evitar dupla contagem e cruzar com a agenda do ERP para um diagnóstico de liquidez de 7, 15 e 30 dias. Inclui o estágio atual do módulo da Malvo, em validação com parceiros.
Ler artigo →
Conciliação bancária automática: como ERPs e BPOs usam Open Finance para fechar o caixa com evidências
Por que a conciliação manual não escala, o que o Open Finance muda e como funciona a conciliação assistida: sugestões de correspondência entre débitos e títulos, com evidências e confirmação humana. Inclui o estágio atual do módulo da Malvo, em validação com parceiros.
Ler artigo →