Só é seguro repetir o que não muda nada quando roda duas vezes: leituras e atualizações de um registro que você já identifica pelo id. Ligar retry em toda chamada externa, "para o fluxo ficar mais robusto", é exatamente como nasce contato duplicado e mensagem enviada em dobro. Antes de repetir, classifique cada chamada.
Por que repetir pode piorar
Quando uma chamada dá timeout, você não sabe o que aconteceu. Pode ser que o servidor nunca tenha recebido o pedido. Pode ser que tenha recebido, processado e só a resposta tenha se perdido no caminho. Repetir cobre o primeiro caso e duplica o segundo.
A palavra técnica para a chamada que pode ser repetida sem efeito extra é idempotente: o resultado de rodar duas vezes é o mesmo de rodar uma. A especificação do HTTP (RFC 9110, seção 9.2.2) define assim: o efeito de várias requisições idênticas deve ser o mesmo de uma só. Dos métodos que ela define, PUT, DELETE e os métodos seguros, como GET, são idempotentes. O POST não é.
A mesma seção diz que um cliente não deve repetir automaticamente uma requisição de método não idempotente, a menos que saiba que a semântica é idempotente de fato ou tenha como detectar que a original nunca foi aplicada. Essa é a regra que o botão de retry de muita ferramenta esconde.
Na documentação do n8n, a opção Retry On Fail é descrita em uma linha: quando a execução do nó falha, ele roda de novo. A página que conferi não faz distinção entre tipos de chamada. Essa distinção é sua.
O que classifiquei
Em agosto de 2026 revisei os nós de chamada externa dos fluxos de um cliente, antes de ligar retry em todos. Separei em cinco grupos:
- Leitura, 43 nós: repetir não muda estado. Pode ter retry.
- Atualização com id, 47 nós: escrever o mesmo valor no mesmo registro duas vezes dá o mesmo registro, então em geral pode ter retry. A exceção é a atualização que dispara uma automação ou um webhook do outro lado a cada escrita, ou que soma em vez de definir ("mais 1" em vez de "igual a 5"): essas eu trato como criação.
- Envio de mensagem, 35 nós: repetiria a mensagem para o contato. Sem retry.
- Criação de registro, 14 nós: duplicaria o contato ou a negociação. Sem retry.
- POST sem efeito conhecido, 27 nós: sem classificação, sem retry.
O CRM desse cliente já tinha um contato duplicado, dois cadastros com o mesmo nome criados com 15 segundos de diferença. Ligar o retry em tudo teria industrializado um defeito que já existia.
Como decidir caso a caso
Faça a pergunta de cada nó: se esta chamada rodar duas vezes e a primeira tiver dado certo, o que acontece?
- Nada de novo (leitura, atualização com id): pode repetir.
- Cria algo ou dispara algo (envio, criação, cobrança): não repita às cegas.
- Não sei: trate como se criasse, até alguém confirmar na documentação da API.
Como tornar uma criação segura para repetir
Se você precisa mesmo repetir uma criação, o que a RFC chama de "meio de detectar que a original nunca foi aplicada" é o que torna isso possível. Na prática:
- Mande uma chave de idempotência, se a API oferecer. Eu não vi isso documentado em todas as APIs que uso, então confirme na da sua.
- Busque antes de criar. Procure o registro pelo telefone, e-mail ou id externo e só crie se não achar. Isso não elimina a corrida entre duas execuções simultâneas, só reduz.
- No banco, use uma restrição de unicidade na chave de negócio. O segundo registro falha em vez de duplicar, e o fluxo para ali.
- Registre cada tentativa com um id próprio, para auditar depois quem repetiu o quê.
Para reprocessar em massa
Quando o problema é um lote que falhou e você vai reprocessar milhares de itens, vale o mesmo critério, aplicado ao lote. Reprocesse primeiro as etapas de leitura e atualização. Para as etapas que criam ou enviam, reprocesse só os itens que você confirmou que não foram aplicados, comparando com o destino. Rodar tudo de novo "porque é mais simples" é a maneira mais rápida de mandar a mesma mensagem duas vezes para a base inteira.
Um caso relacionado, em que a duplicação vem da própria plataforma e não do seu retry, está em por que a Meta entrega o mesmo evento duas vezes.