Por que a Meta entrega o mesmo evento duas vezes e o seu sistema responde em dobro?

Porque o webhook da Meta não garante entrega única. A documentação diz que a Meta tenta de novo quando uma entrega falha e que o seu servidor deve tratar as repetições. Nos meus testes no Instagram, vi o mesmo evento chegar duas vezes com 2 a 71 milissegundos de diferença, rápido demais para ser uma nova tentativa depois de uma falha, e a documentação não explica esse caso. Descobrir o motivo não resolve nada. O que resolve é o fluxo reconhecer que já viu aquela mensagem. Conferi a documentação em 9 de outubro de 2026.

O que a Meta documenta

Um webhook é um aviso que a Meta envia para o seu sistema cada vez que algo acontece, como uma mensagem nova. O que a documentação diz sobre falhas:

• No WhatsApp, se o seu endereço responde com outro código que não seja 200, ou se a entrega falha por outro motivo, a Meta repete com frequência decrescente por até 7 dias. Ela avisa que essas repetições podem gerar notificações duplicadas.
• Na documentação de webhooks da Graph API e na do Instagram, a Meta tenta de novo logo em seguida e depois mais algumas vezes ao longo de 36 horas. A frase é direta: o seu servidor deve cuidar da deduplicação nesses casos.
• A documentação do Messenger pede resposta 200 OK em até 5 segundos.
• As notificações podem chegar em lote de até 1.000, e a Meta diz que o lote não é garantido, então cada webhook deve ser tratado sozinho.

Resumindo o que isso promete: pelo menos uma vez, não exatamente uma vez.

O que vi na prática

Num fluxo em produção que responde mensagens diretas do Instagram, apareceram pares de execuções do mesmo evento, com intervalo entre 2 e 71 milissegundos. Eram duas execuções paralelas do mesmo fluxo, e cada uma ia responder. Não sei a causa: a documentação fala de repetição depois de falha, e aqui as duas entregas chegaram juntas. Por isso trato como comportamento da plataforma e protejo o fluxo, sem apostar no motivo.

Por que a resposta sai em dobro

Duas execuções começam quase ao mesmo tempo. Cada uma pergunta "já respondi essa mensagem?". Nenhuma terminou de gravar a resposta, então as duas ouvem "não" e as duas respondem. É uma corrida, e o resultado é o cliente recebendo a mesma resposta duas vezes.

Duas tentativas não funcionaram no meu teste:

• Guardar os IDs já vistos no estado do próprio fluxo (no n8n, o $getWorkflowStaticData). As execuções paralelas leem o estado vazio antes de qualquer uma gravar.
• Limitar o fluxo a uma execução por vez. Isso não serializou as execuções no meu teste.

O que funcionou

Uma sequência de três passos antes de qualquer resposta: o gatilho, uma checagem e o nó Remove Duplicates, do próprio n8n.

O Remove Duplicates, na operação que remove itens processados em execuções anteriores, compara o item novo com o que foi guardado antes. No modo "Value Is New", ele descarta o item cujo valor já apareceu. A chave que eu uso é o ID da mensagem (message.mid, no caso das mensagens diretas) ou o ID do comentário (value.id). Só a saída dos itens novos segue conectada ao resto do fluxo, então a cópia duplicada termina ali. A documentação do n8n diz que, por padrão, ele guarda 10.000 itens, e que o escopo pode ser o nó ou o fluxo inteiro. Em volume alto, aumente o histórico.

Validei isso em dois pares de execuções reais: em cada par, só uma das duas seguiu para a resposta.

A checagem que vem antes do Remove Duplicates descarta três coisas:

• O eco. Quando o agente responde, a própria resposta volta como um novo evento. A documentação do Instagram trata desses eventos de eco, marcados com is_echo. Sem esse filtro, o agente passa a conversar com ele mesmo.
• Os eventos de leitura e de entrega, que não são mensagem.
• As mensagens sem texto nem anexo. Sem esse filtro, o agente de IA recebe um pedido vazio e erra.

O que fazer

1. Responder 200 depressa e deixar o trabalho pesado para depois. Se o fluxo demora mais que o prazo de 5 segundos do Messenger, ele corre o risco de gerar repetição.
2. Deduplicar pelo ID da mensagem, antes de qualquer resposta ou gravação.
3. Quando o fluxo não for no n8n, ou quando precisar de garantia forte, usar uma chave única no banco: o segundo registro com o mesmo ID falha, e o fluxo para ali.
4. Testar com dois envios simultâneos do mesmo evento antes de ligar em produção. Não vi, na documentação do n8n, uma garantia de que o nó seja atômico entre execuções simultâneas. O que eu tenho é o teste.

Atendimento no WhatsApp com IA: como eu monto e opero isso.