Mensagem repetida no WhatsApp, uma só encomenda
«Eu só pedi uma vez. Porque é que tenho duas encomendas?»
É a conversa que queres evitar com o teu cliente. Ele confirma um pedido pelo WhatsApp. A integração recebe a notificação, cria a encomenda no ERP e, por uma falha na comunicação, volta a receber o mesmo evento. Se tratar cada entrega como uma nova intenção de compra, tens duas encomendas para um único pedido.
A resposta do assistente até pode estar impecável. O problema está no que aconteceu depois: duas tarefas de preparação, duas reservas de stock ou trabalho administrativo para desfazer o erro.
A diferença entre responder bonito e integrar o teu ERP aparece aqui. Não na capacidade de escrever «pedido recebido», mas na capacidade de provar que uma confirmação só produz uma encomenda, mesmo quando a infraestrutura repete a entrega.
A mesma notificação pode chegar mais de uma vez
Um webhook é uma notificação enviada de um sistema para outro. Quando chega uma mensagem, a plataforma avisa a tua integração por HTTP. A integração acusa a receção e trata o evento.
Segundo a documentação de webhooks do WhatsApp da Meta consultada para este artigo, as entregas que falham ou não recebem a resposta HTTP 200 podem ser novamente tentadas durante até sete dias. A própria documentação admite notificações repetidas. Isto não significa que todas as mensagens sejam repetidas nem que a plataforma duplique encomendas. Significa que quem constrói a integração não pode assumir uma entrega única.
Pensa numa chamada telefónica que cai depois de dizeres «está confirmado». A outra pessoa não sabe se ouviste. Repetir a frase é uma forma razoável de recuperar a comunicação. Repetir a compra não é.
Há também relatos públicos da dor na conversa. Na issue 221827 do Odoo, aberta em agosto de 2025 sobre a versão 18.0, um utilizador descreve que o cliente recebe a mensagem duas vezes quando mensagens de entrada e saída se cruzam. O relato é sobre mensagens, não sobre encomendas duplicadas. Não prova uma falha de criação de encomendas. Mostra por que motivo convém separar o que aparece no chat do que ficou efetivamente registado no ERP.
O exemplo: dez caixas, uma confirmação, duas entregas
Imagina um distribuidor. Este é um exemplo de teste, não um resultado de uma instalação Leiritech.
O cliente pede dez caixas de um artigo. O sistema identifica o cliente e a referência no ERP, apresenta o resumo e recebe a confirmação. Essa confirmação fica associada a uma operação concreta, por exemplo pedido-482. O nome é ilustrativo; interessa existir uma identidade estável para aquela decisão de compra.
A primeira entrega do evento leva à criação da encomenda. O ERP grava-a, mas a resposta perde-se antes de a integração conseguir registar o sucesso. Entretanto, chega outra entrega da mesma confirmação.
Uma implementação ingénua volta a executar «criar encomenda». Uma implementação preparada reconhece a operação e apura o resultado anterior antes de avançar. Se confirmar que a encomenda já existe, associa-lhe a operação e devolve a referência existente. Não cria uma segunda.
É isto que se procura com idempotência: repetir a mesma operação não acrescenta outro efeito de negócio. Não significa impedir que um cliente faça duas compras iguais. Significa impedir que a infraestrutura transforme uma compra em duas.
Essa distinção muda o desenho da integração. Há duas identidades a preservar: a do evento recebido, para reconhecer a repetição da notificação, e a da operação confirmada, para reconhecer a mesma encomenda ao longo das tentativas de execução.
O texto da mensagem não chega para nenhuma das duas. «Quero dez caixas» pode ser uma compra legítima hoje e outra amanhã. Eliminar mensagens iguais durante alguns minutos pode esconder a falha técnica à custa de apagar pedidos válidos.
A proteção tem de existir antes da escrita
Uma memória da conversa não é um mecanismo de exclusão. Dizer ao modelo «não dupliques encomendas» também não é. Dois processos podem receber o mesmo evento ao mesmo tempo, consultar o histórico, não encontrar nada e avançar ambos.
O primeiro controlo é uma receção durável. A integração valida a origem da notificação e guarda o evento antes de acusar a receção. A identificação deve incluir o contexto necessário, como a empresa ou conta e o identificador da mensagem ou do evento relevante. Não basta marcar um pacote inteiro como tratado se esse pacote contiver vários eventos distintos.
O registo tem de impedir duplicados de forma atómica: numa base de dados, uma restrição de unicidade pode garantir que apenas um processo consegue registar aquela identidade. Consultar primeiro e inserir depois, sem essa proteção, deixa aberta a corrida entre processos.
Só depois de guardar duravelmente o evento faz sentido devolver o HTTP 200 e continuar o trabalho através de uma fila. Assim, a receção não fica dependente de esperar pela criação da encomenda. Mas isto resolve apenas a entrada. Se o processo cair depois de guardar o evento, tem de existir uma forma de retomar o trabalho; «já recebido» não pode passar a significar «esquecido».
A operação precisa, portanto, de um estado persistente: recebida, em processamento, confirmada ou com resultado por apurar. Uma segunda entrega consulta esse estado. Não volta a entregar ao modelo uma autorização em branco para comprar.
O ponto difícil: o ERP gravou, mas ninguém recebeu a resposta
Um timeout diz que não recebeste a resposta a tempo. Não diz que o ERP recusou a operação.
Esta é a falha que uma demonstração sem interrupções não revela. A integração pode guardar todos os eventos corretamente e, ainda assim, duplicar uma encomenda se repetir uma escrita cujo resultado desconhece.
A melhor proteção depende da API concreta. Se aceitar uma chave de idempotência, todas as tentativas daquela operação devem usar a mesma chave. Se permitir uma referência externa com unicidade efetivamente imposta na criação, essa referência pode cumprir uma função semelhante. É preciso verificar a garantia, a duração e o âmbito dessa proteção na versão utilizada; um campo chamado «referência» não implica unicidade.
Pesquisar a referência antes de criar ajuda a reconciliar, mas, isoladamente, não fecha o problema. Duas tentativas podem pesquisar ao mesmo tempo e ambas concluir que ainda não existe encomenda. A proteção da escrita tem de ser garantida no destino ou por um mecanismo que controle efetivamente as tentativas e as falhas relevantes.
Se a API não oferecer uma forma fiável de distinguir «não foi criado» de «foi criado, mas a resposta perdeu-se», a opção segura é suspender a repetição automática e encaminhar a operação para reconciliação. Nesse momento, a mensagem correta é «estamos a verificar o registo», não «a encomenda falhou» nem «já está confirmada».
Há aqui uma escolha operacional: perante incerteza, preferes atrasar uma confirmação ou arriscar uma segunda encomenda? A integração deve tornar essa decisão explícita. Prometer «exatamente uma vez» sem explicar esta fronteira entre sistemas não resolve nada.
Consultar o ERP não é ter autorização para escrever nele
Na Leiritech, o acesso conversacional ao ERP é apresentado como só de leitura, auditado e fundamentado nos dados do cliente. Essa fronteira importa: consultar uma encomenda e criar uma encomenda são permissões diferentes.
Um assistente só de leitura pode verificar a existência do pedido, consultar o estado e apresentar a referência que encontrou. Não cria documentos, não reserva stock e não deve alegar que executou uma ação que as suas permissões não permitem.
Para acrescentar criação de encomendas, é necessário um fluxo de escrita separado, autorizado e implementado para o teu sistema. O modelo pode ajudar a interpretar o pedido e a apresentar o resumo. A execução deve passar por regras determinísticas: identidade do cliente, empresa certa, artigos válidos, confirmação, permissões e controlo de repetição.
Ter a resposta fundamentada nos dados reais reduz o espaço para inventar referências ou estados. Não substitui a proteção transacional. A linguagem natural trata da conversa; o conector e o ERP têm de garantir o efeito da operação.
O desenho aqui descrito é uma proposta de implementação e teste. Não é uma afirmação de que qualquer ERP, versão ou conector disponível já oferece estas garantias.
O custo da duplicação muda conforme o teu trabalho
Num armazém, uma encomenda repetida pode originar uma segunda tarefa de preparação. Mesmo que alguém detete o erro antes da expedição, já houve tempo gasto a separar material ou a desfazer reservas. O teste deve acompanhar a encomenda até à tarefa que ela desencadeia, não terminar quando o chat responde.
Num laboratório de calibração, a confirmação de um serviço pode abrir um processo de trabalho associado a equipamentos concretos. Receber outra vez a mesma confirmação não deve criar um segundo processo para a mesma operação. Dois serviços efetivamente encomendados continuam, naturalmente, a precisar de identidades diferentes.
Na saúde ou num lar, considera um pedido autorizado de consumíveis à farmácia ou ao fornecedor. Uma confirmação repetida não deve duplicar a requisição. Isto não autoriza um assistente a alterar medicação ou a executar decisões clínicas; o exemplo limita-se ao circuito de aprovisionamento e às suas permissões.
Na faturação eletrónica, quando o processo inclui emissão, uma resposta perdida não permite concluir que o documento não existe. Antes de repetir a operação, tens de consultar e reconciliar o resultado pelos mecanismos do sistema aplicável. Um identificador de conversa não substitui a identidade documental nem as regras fiscais.
Nos quatro casos, o objetivo é o mesmo: a repetição técnica não pode passar silenciosamente a ser uma nova decisão de negócio.
«Mas um bot de 25 euros também recebe pedidos»
Pode receber, organizar a conversa e encaminhar para a equipa. Isso pode ser exatamente o que precisas. O problema começa quando «receber um pedido» é vendido ou entendido como «executar uma encomenda segura no ERP».
Na oferta publicada pela 3HASH em junho de 2026, o conjunto site e WhatsApp soma 25 euros por mês, com IVA incluído, e tem 100 euros de configuração. A página descreve respostas, recolha de contactos e encaminhamento. Não especifica uma integração ERP nesse pacote. A mesma empresa anuncia integrações empresariais noutra oferta, sob consulta. Não seria correto concluir que não as sabe construir.
Também não seria correto dizer que só a Leiritech conhece este problema. A Agathas, num artigo de outubro de 2026 sobre integração ERP–WhatsApp, já descreve fila e deduplicação. A oportunidade não está em usar uma palavra técnica que ninguém conhece. Está em demonstrar que a proteção funciona no teu ERP, na tua operação e quando a comunicação falha.
O preço mensal, por si só, não prova essa capacidade. Pede o âmbito e o teste. Um assistente de atendimento e uma integração com responsabilidade sobre escritas podem partilhar a janela de chat sem serem o mesmo produto.
O teste que vale mais do que uma resposta bonita
A Black Friday de 2026 é a 27 de novembro, data indicada no Calendarr: a 23 de outubro, faltam 35 dias. Não é uma previsão de tráfego nem uma razão para ligar escritas à pressa. É uma janela para testar antes de dependeres do fluxo.
Num ambiente controlado, sem expedições ou emissão fiscal reais, confirma uma encomenda de teste e entrega duas vezes o mesmo evento. Repete também com as duas entregas em simultâneo. Depois simula a interrupção no ponto mais incómodo: o ERP já gravou, mas a integração ainda não sabe.
O resultado aceitável não é apenas «o bot respondeu uma vez». Deves conseguir seguir a cadeia: evento recebido, operação identificada, tentativa de execução, referência efetiva no ERP e tratamento da repetição. Se o resultado estiver incerto, deve ficar visivelmente pendente, sem nova criação automática.
Consulta também os efeitos seguintes. Uma encomenda única com duas tarefas de preparação continua a ser uma falha. E faz o teste inverso: duas compras legítimas com conteúdo igual têm de continuar a produzir duas operações distintas.
A auditoria deve permitir reconstruir o que aconteceu, com identificadores, estados, instantes e autorizações relevantes. Não exige guardar indefinidamente conversas completas nem expor dados pessoais a quem não precisa deles. Exige prova suficiente para distinguir uma repetição evitada de um pedido perdido.
Envia para hello@leiritech.com o nome e a versão do teu ERP e a operação que queres ligar ao WhatsApp. O próximo passo é definir um teste de repetição controlado: duas entregas da mesma confirmação, uma só encomenda e um registo que explique porquê.
