Foto: Valeria Reverdo / Unsplash
Automações
Fazer o endpoint do webhook processar tudo antes de responder faz o provedor entender que falhou, reenviar o evento e duplicar o trabalho
Pedro Toledo · 8 de novembro de 2026 · 3 min de leitura
Fazer o endpoint do webhook processar tudo antes de responder faz o provedor entender que falhou, reenviar o evento e duplicar o trabalho — porque quem envia o aviso só espera uma resposta de sucesso rápida, e uma tarefa longa estoura o tempo limite e conta como erro mesmo quando terminou. Por que processar na hora parecer o jeito certo, o que caracteriza responder primeiro e trabalhar depois, e como proteger contra duplicidade.
O endpoint do webhook parece funcionar quando o teste devolve o resultado certo. Medir quanto tempo a resposta leva em um evento real mostra se o provedor vai achar que deu certo.
Fazer o endpoint do webhook processar tudo antes de responder faz o provedor entender que falhou, reenviar o evento e duplicar o trabalho.
Por que processar na hora parece o jeito certo
A lógica fica toda num lugar só e o teste simples dá o resultado esperado. Só que o provedor não espera indefinidamente: se a resposta demora, ele a trata como falha e reenvia o evento, e a automação que já fez o trabalho passa a recebê-lo de novo e a repeti-lo.
O que caracteriza responder primeiro e trabalhar depois
Responder primeiro é validar o aviso, guardá-lo numa fila ou tabela, devolver o sucesso e deixar o processamento para um segundo passo, com retentativa e alerta. Isso tem relação direta com configurar o webhook com chave secreta desatualizada ou incorreta — ambos fazem o evento se perder ou se repetir sem erro visível, e a diferença está em o aviso ser recebido, confirmado e registrado antes de qualquer trabalho.
O que as fontes dizem
A documentação do Stripe diz que o endpoint deve devolver um 2xx antes de lógica complexa que possa causar timeout, e o artigo de suporte recomenda confirmar de imediato e usar uma fila para tarefas longas. Guias de terceiros citam cerca de 20 ou 30 segundos de limite e retentativas por dias, sem que eu tenha conseguido confirmar na documentação. Também recomendam registrar o identificador do evento depois de processar.
Como proteger contra duplicidade
A forma prática é guardar o identificador de cada evento recebido e verificar se ele já foi processado antes de agir, de modo que um reenvio não duplique a ação. Depois, medir o tempo de resposta do endpoint em eventos reais e criar um alerta para os que falharem depois das retentativas, com alguém responsável por olhar.
Um exemplo prático
Um fluxo envia o acesso de um curso quando chega o aviso de pagamento, e a geração do acesso e do e-mail leva quase um minuto. O provedor reenvia o aviso, e alguns alunos recebem dois e-mails. Depois, o endpoint passa a gravar o evento, responder em segundos e processar em segundo plano, com checagem do identificador.
O ponto central
Antes de colocar o webhook em produção, vale perguntar quanto tempo ele leva para responder. Quem confirma primeiro e trabalha depois tira do provedor a razão de reenviar.
