Receber o mesmo webhook duas vezes pode parecer um problema pequeno, mas as consequências podem ser importantes: mensagens enviadas em duplicidade, pedidos criados novamente, registros repetidos no CRM e cobranças processadas mais de uma vez. Para evitar execuções duplicadas no n8n, não basta apenas remover itens iguais dentro de uma execução. É necessário garantir que o mesmo evento não seja processado novamente, mesmo que ele chegue em outro momento.

A solução passa pelo conceito de idempotência. Em uma automação idempotente, executar a mesma operação duas ou mais vezes produz o mesmo resultado final da primeira execução. Para alcançar esse comportamento no n8n, podemos combinar identificadores únicos, armazenamento persistente e uma verificação antes das ações que geram efeitos externos.

Por que um webhook pode chegar duplicado?

Webhooks são notificações enviadas por uma plataforma para informar que determinado evento aconteceu. Quando um pagamento é aprovado, um formulário é enviado ou um pedido é criado, o sistema de origem faz uma requisição para a URL configurada no n8n.

Essa comunicação, porém, nem sempre acontece uma única vez. A plataforma pode reenviar o webhook quando não recebe uma resposta dentro do tempo esperado, quando ocorre uma falha de conexão ou quando existe uma política automática de tentativas.

Também é possível que o n8n conclua uma operação em um serviço externo, mas não receba a confirmação esperada. Se o node estiver configurado com Retry On Fail, uma nova tentativa pode repetir uma ação que já foi concluída no destino.

Por isso, duplicidade nem sempre significa que o n8n apresentou uma falha. Muitas vezes, ela é uma consequência natural de integrações distribuídas e precisa ser considerada durante a construção do workflow.

Filtrar itens repetidos não é o mesmo que impedir reprocessamentos

O node Remove Duplicates é útil para comparar dados e remover itens repetidos. Ele pode atuar sobre os itens da execução atual ou comparar valores com execuções anteriores, conforme a operação e o escopo configurados.

Esse recurso funciona bem em fluxos nos quais existe um campo estável para comparação. Entretanto, a proteção de uma operação crítica não deve depender apenas da semelhança entre objetos completos. Datas, status, campos calculados e alterações na ordem das propriedades podem fazer duas versões do mesmo evento parecerem diferentes.

O ideal é identificar uma chave que represente o evento de maneira inequívoca, como:

• ID do pagamento;
• ID do pedido;
• ID da mensagem recebida;
• ID da submissão do formulário;
• identificador do evento fornecido pela API;
• combinação controlada de campos quando não existe um ID nativo.

Se a plataforma já envia um identificador único, ele deve ser priorizado. Criar uma chave baseada apenas em nome, telefone ou horário pode gerar falsos positivos e bloquear eventos legítimos.

Estrutura recomendada para um workflow idempotente

Um workflow protegido pode ser organizado em cinco etapas. A primeira recebe o webhook. A segunda extrai o identificador do evento. A terceira consulta um registro persistente para descobrir se a chave já foi processada. A quarta encerra duplicidades. A quinta executa a operação e registra o identificador.

1. Receber o evento pelo Webhook node.
2. Extrair e validar o identificador único.
3. Consultar a chave em uma Data Table ou banco externo.
4. Interromper o fluxo se a chave já existir.
5. Processar o evento e registrar seu identificador.

A ordem é importante. Se o identificador for salvo somente muito tempo depois da ação principal, duas execuções simultâneas poderão consultar o registro antes que qualquer uma delas grave a chave. As duas entenderão que o evento é novo e continuarão.

Em operações sensíveis, a reserva da chave precisa acontecer de maneira atômica. Isso pode ser feito com uma restrição de unicidade no banco de dados ou uma operação que falhe caso o identificador já exista.

Esse cuidado torna o workflow mais confiável do que uma simples sequência “consultar e depois criar”, especialmente quando há concorrência.

Quando usar Remove Duplicates, Data Tables ou banco externo

Remove Duplicates

É indicado quando o objetivo é eliminar itens repetidos dentro de um conjunto ou comparar determinados campos com execuções anteriores. É uma solução rápida para fluxos de menor criticidade e para listas processadas em lote.

Data Tables

As Data Tables permitem manter dados estruturados dentro do próprio n8n. A documentação cita como caso de uso o armazenamento de marcadores para impedir execuções duplicadas ou controlar triggers.

Elas podem registrar o ID, a data de processamento, o tipo do evento, o status e até o ID da execução responsável. Isso facilita auditorias e investigações quando algo não acontece como esperado.

Banco de dados externo

PostgreSQL, MySQL ou Redis são alternativas mais adequadas quando existe grande volume, múltiplos workflows compartilhando os mesmos eventos ou necessidade de controle transacional.

Em um banco relacional, por exemplo, o identificador do evento pode ter uma restrição unique. A primeira tentativa consegue inserir o registro, enquanto as seguintes encontram a chave existente e são interrompidas.

Para entender em quais cenários o n8n oferece mais controle de infraestrutura, vale consultar também o artigo sobre as diferenças entre n8n e Make.

Cuidados com retries e respostas do webhook

O Retry On Fail ajuda a recuperar falhas temporárias, como limites de requisições ou indisponibilidade de uma API. Entretanto, ele deve ser aplicado com cuidado em nodes que criam pedidos, enviam mensagens ou executam cobranças.

Imagine que a API concluiu a operação, mas a conexão foi interrompida antes de devolver a resposta. Para o n8n, a chamada falhou. Para o sistema de destino, a ação foi realizada. Uma nova tentativa sem idempotência poderá repeti-la.

Quando a API de destino aceita uma chave de idempotência, envie a mesma chave em todas as tentativas do evento. Quando não aceita, registre localmente a operação e consulte o destino antes de repetir uma ação crítica.

Outro ponto é a resposta do Webhook node. Se o sistema de origem exige uma confirmação rápida, evite deixá-lo aguardando todo o processamento. Dependendo do caso, responda ao webhook e encaminhe o trabalho para outro workflow. Isso reduz reenvios provocados por timeout, mas exige que a fila ou o mecanismo intermediário também seja confiável.

Como monitorar duplicidades e falhas

Impedir duplicidades não significa apagar qualquer evidência delas. O ideal é registrar que um evento repetido foi identificado, incluindo o ID, horário, origem e motivo do bloqueio.

Configure também um Error Workflow para receber falhas do fluxo principal. Ele pode enviar uma notificação, registrar o erro em uma tabela ou encaminhar o caso para análise. Essa observabilidade ajuda a separar duplicidades legítimas de problemas de configuração.

Automatizações mais maduras precisam responder a algumas perguntas:

• Qual evento iniciou esta execução?
• Esse identificador já havia sido recebido?
• A ação externa foi concluída?
• Uma nova tentativa é segura?
• Por quanto tempo a chave deve permanecer armazenada?

Esse tipo de controle é especialmente importante em projetos que reaproveitam conteúdo ou realizam publicações automáticas. Um exemplo relacionado está no conteúdo sobre automação de posts com IA e n8n.

Erros comuns ao tentar evitar duplicidade

• Comparar o objeto inteiro em vez de usar um ID estável.
• Salvar a chave somente depois de todas as ações externas.
• Não considerar duas execuções ocorrendo ao mesmo tempo.
• Ativar retries em operações não idempotentes.
• Guardar identificadores indefinidamente sem política de retenção.
• Tratar todo evento parecido como duplicado.
• Não registrar quando um evento é bloqueado.

O armazenamento usado também deve acompanhar o volume da automação. O método de dados estáticos do workflow pode ser útil em situações simples, mas a própria documentação do n8n alerta que ele pode se comportar de maneira pouco confiável em execuções de alta frequência. Para cenários importantes, prefira Data Tables ou uma base projetada para esse controle.

Perguntas frequentes

O Remove Duplicates impede qualquer webhook duplicado?

Não automaticamente. Ele precisa ser configurado com os campos e o escopo adequados. Para ações críticas, combine a verificação com uma chave única armazenada de forma persistente.

Posso usar o ID da execução do n8n como chave?

Não é o ideal, pois cada nova execução terá outro ID. A chave deve vir do evento ou representar a operação no sistema de origem.

Por quanto tempo devo guardar os identificadores?

Isso depende da possibilidade de reenvio e das regras do processo. Pagamentos e pedidos podem exigir retenção maior, enquanto notificações menos críticas podem usar uma janela limitada.

Retry On Fail sempre gera duplicidade?

Não. O risco aparece quando a ação foi concluída no destino, mas o n8n recebeu uma falha ou não recebeu a resposta. Uma chave de idempotência reduz esse problema.

Data Tables substituem um banco de dados?

Elas atendem muitos fluxos internos, mas operações com grande volume, concorrência elevada ou requisitos transacionais podem exigir um banco externo.

Conclusão

Para evitar execuções duplicadas no n8n, trate cada webhook como um evento que precisa ter identidade própria. Extraia uma chave confiável, consulte um registro persistente e bloqueie o reprocessamento antes de executar ações externas.

Remove Duplicates é útil para filtros e comparações, enquanto Data Tables e bancos externos permitem um controle mais completo. Em operações críticas, considere ainda concorrência, retries, timeouts e restrições de unicidade. O resultado é uma automação mais previsível, auditável e segura para crescer.

Rafael Feitosa