Foto: Scott Rodgerson / Unsplash
Automações
Processar o webhook inteiro antes de responder ao sistema de origem faz a resposta demorar, estourar o prazo e gerar reenvio do mesmo evento, que a automação processa duas vezes
Pedro Toledo · 30 de outubro de 2026 · 3 min de leitura
Processar o webhook inteiro antes de responder ao sistema de origem faz a resposta demorar, estourar o prazo e gerar reenvio do mesmo evento, que a automação processa duas vezes — porque o sistema que envia o evento espera uma confirmação rápida, e quando ela não chega, entende que a entrega falhou e tenta de novo, enquanto o processamento da primeira tentativa ainda estava em andamento. Por que fazer tudo na mesma chamada parecer o jeito mais simples, o que caracteriza um recebimento que confirma primeiro e processa depois, e como perceber se o fluxo já está recebendo eventos em duplicidade.
Fazer todo o trabalho dentro da chamada que recebe o webhook costuma parecer o jeito mais simples de construir o fluxo. Comparar o tempo de resposta do endpoint com o limite do provedor, e procurar o mesmo evento processado duas vezes, revela o que o teste com um único evento não mostra.
Processar o webhook inteiro antes de responder ao sistema de origem faz a resposta demorar, estourar o prazo e gerar reenvio do mesmo evento, que a automação processa duas vezes — porque o remetente entende que a entrega falhou.
Por que fazer tudo na mesma chamada parece o jeito mais simples
O código é linear: receber, gravar, enviar e-mail, atualizar o CRM e só então responder. Nos testes, cada passo é rápido e tudo funciona. Em produção, um passo lento, como uma API externa ou um volume maior, alonga a resposta além do que o remetente tolera, e ele tenta de novo enquanto o primeiro processamento ainda está em curso.
O que caracteriza um recebimento que confirma primeiro e processa depois
Um recebimento adequado valida o evento, grava-o com seu identificador e responde com sucesso em milissegundos, deixando o processamento pra um segundo passo. Isso tem relação direta com processar o dado recebido via webhook sem nenhuma validação real antes de aplicar no próprio sistema — os dois casos apontam pro mesmo princípio de fundo: o webhook é uma porta de entrada que precisa ser tratada com cuidado, seja pela validação do que chega, seja pela rapidez e pela proteção contra repetição na hora de responder.
O que os guias dizem sobre o prazo e a duplicidade
O blog da Stripe pra desenvolvedores recomenda devolver rapidamente uma resposta 2xx e tratar o processamento de forma assíncrona, e avisa que a plataforma pode enviar o mesmo evento mais de uma vez, sugerindo guardar os identificadores dos eventos pra checar duplicidade. Os guias que encontrei divergem sobre o prazo exato, de 5 a 20 segundos ou nenhum número publicado, e a documentação do seu provedor é a referência.
Como perceber se o fluxo já recebe eventos duplicados
A forma prática é procurar, no histórico dos últimos 30 dias, o mesmo identificador de evento processado mais de uma vez e comparar o tempo de resposta do endpoint com o limite do provedor. Duplicidade e respostas lentas juntas apontam o problema, e a correção costuma ser responder primeiro e processar depois, com checagem de identificador.
Um exemplo prático
Uma loja recebe a confirmação de pagamento por webhook e, na mesma chamada, emite a nota fiscal, envia o e-mail e atualiza o CRM. Num dia de volume alto, a emissão da nota demora, o provedor reenvia o evento e alguns clientes recebem duas notas e dois e-mails. Depois, a loja passa a gravar o evento e responder em milissegundos, processa a fila em segundo plano e ignora identificadores já tratados.
O ponto central
Antes de colocar um webhook no ar, vale separar o recebimento do processamento. Responder rápido e processar depois evita que a lentidão de um passo vire o mesmo evento chegando duas vezes.
