Se o formulário do seu site é a forma como os novos clientes chegam até si, cada pedido de contacto conta. E se usa o n8n, uma ferramenta que liga as suas aplicações e trata de tarefas rotineiras automaticamente, ligar o formulário ao n8n é o passo natural. Alguém preenche o formulário, o n8n adiciona essa pessoa ao seu CRM (o sistema que guarda a sua lista de clientes e o seu funil de vendas) e envia os emails de seguimento. O atalho é enviar o formulário diretamente para o n8n, e pode ficar a funcionar numa tarde. Percebemos porque é que se faz. Também vemos o que normalmente acontece a seguir: spam no CRM, uma automação em que ninguém se atreve a tocar e, de vez em quando, um pedido de contacto que simplesmente desaparece.
Este artigo explica o que corre mal e a configuração mais segura que recomendamos em alternativa. A versão curta: deixe que seja o seu próprio site a receber o formulário primeiro e a verificá-lo. Só depois deve passar o pedido de contacto ao n8n.
O que corre mal quando o formulário vai diretamente para o n8n
- Qualquer pessoa consegue descobrir para onde o seu formulário envia as mensagens. Esse endereço está escrito na sua página web, por isso qualquer pessoa pode enviar-lhe o que quiser, as vezes que quiser.
- Nada é verificado à entrada. Endereços de email inválidos, mensagens enormes e informação que nunca pediu entram diretamente na sua automação e, muitas vezes, no seu CRM.
- Nada trava uma enxurrada. Um único programa pode enviar o formulário milhares de vezes, enchendo o seu CRM de lixo e enviando milhares de emails em nome da sua empresa.
- Os pedidos perdidos passam despercebidos. Se o n8n estiver a reiniciar para uma atualização quando alguém envia o formulário, essa pessoa vê um erro e desiste, e ninguém fica a saber que se perdeu um potencial cliente.
- O seu sistema de automação fica exposto. Para receber o formulário diretamente, o n8n tem de aceitar mensagens de qualquer pessoa na internet.
A configuração mais segura: primeiro o seu site, depois o n8n
O formulário envia o pedido de contacto para o seu próprio site, que já lá está para mostrar as suas páginas. Só depois de o site verificar e aceitar o pedido é que o passa ao n8n, nos bastidores. Os visitantes nunca ficam a saber onde está o n8n. E o formulário pode continuar a funcionar mesmo quando o navegador de alguém bloqueia scripts.
Antes de passar o que quer que seja, o seu site deve fazer uma série de verificações. As rápidas e simples vêm primeiro, para que o lixo óbvio seja rejeitado logo à partida:
- Verificações básicas. Só é aceite um envio normal de formulário: sem carregamento de ficheiros, nada num formato inesperado e nada acima de um tamanho definido, o que é verificado antes mesmo de a mensagem ser lida.
- De onde veio. A mensagem tem de vir de uma página do seu próprio site. Um programa consegue falsificar isto, por isso é um primeiro filtro, não uma fechadura.
- Com que frequência. Cada visitante tem um número limitado de tentativas, e só uma parte mais pequena dessas pode tornar-se pedidos de contacto, para que um único programa não o consiga inundar. Para manter a contagem, o seu site guarda o endereço de internet de cada visitante apenas de forma codificada, nunca em texto legível.
- Um código de utilização única. Quando o seu site mostra o formulário, acrescenta um código escondido que só o seu site poderia ter emitido. Cada código funciona uma vez, por isso um duplo clique ou um envio repetido chega ao n8n só uma vez, e um envio sem código válido não vai a lado nenhum.
- Verificações discretas contra bots, os programas que preenchem formulários automaticamente. Sinais simples que as pessoas reais nunca acionam apanham a maioria deles, sem obrigar os seus visitantes a resolver um puzzle.
- Só os campos que pediu. O envio tem de corresponder aos campos que o seu formulário realmente tem. Qualquer coisa inesperada, mesmo um único campo a mais, faz com que seja rejeitado, para que ninguém consiga introduzir informação extra na sua automação.
- Respostas verificadas e limpas. Cada resposta é verificada quanto ao comprimento e ao formato, por isso um endereço de email tem de parecer um endereço de email. Caracteres invisíveis e espaçamento desarrumado são removidos.
Como o n8n sabe que um pedido de contacto é genuíno
Quando o seu site aceita um pedido de contacto, envia ao n8n uma cópia limpa, apenas com a informação esperada. Com ela seguem três etiquetas: a hora a que foi enviada, um número de referência e uma assinatura digital. A assinatura é calculada a partir dessa hora e do conteúdo exato da mensagem, com um segredo que só o seu site e o n8n conhecem.
A primeira coisa que o n8n faz é verificar essa assinatura, e rejeita tudo o que tenha mais do que alguns minutos. Uma mensagem que tenha sido alterada, com a data modificada ou enviada por alguém sem o segredo não passa daí. Em termos simples, mesmo quem descobrir o n8n não consegue introduzir pedidos falsos nos seus sistemas. Para o seu programador: ative a opção de corpo em bruto (“Raw Body”) do nó Webhook, para que a verificação corra sobre a mensagem exata que foi assinada. A verificação no n8n tem este aspeto:
const crypto = require("crypto");
function isValidDelivery(rawBody, timestamp, signature, secret) {
const age = Math.abs(Date.now() / 1000 - Number(timestamp));
if (!Number.isFinite(age) || age > 300) return false; // janela de 5 minutos
const expected =
"sha256=" +
crypto.createHmac("sha256", secret).update(`${timestamp}.${rawBody}`).digest("hex");
const a = Buffer.from(expected);
const b = Buffer.from(signature ?? "");
return a.length === b.length && crypto.timingSafeEqual(a, b);
}O número de referência também é importante. Se o seu site tiver de enviar um pedido de contacto outra vez, usa o mesmo número, para que o n8n perceba que já adicionou esse contacto e não crie um duplicado.
O que acontece se o n8n estiver indisponível
Os sistemas de automação reiniciam para atualizações, e as ligações à internet têm maus momentos. Se o seu site não conseguir chegar ao n8n, não deve mostrar um erro ao visitante. Em vez disso, pode guardar o pedido numa pequena área de espera encriptada no servidor e dizer ao visitante que a mensagem foi recebida, o que é verdade. O seu site tenta depois outra vez, de forma programada, com o mesmo número de referência. Os pedidos que continuarem sem poder ser entregues ao fim de um tempo definido devem ser apagados e uma pessoa avisada, para que os dados pessoais não fiquem à espera indefinidamente.
Só se o n8n e a área de espera falharem ambos é que o visitante deve ver um erro, com um endereço de email para onde escrever em alternativa. A única coisa que nunca pode acontecer é dizer a alguém que a mensagem foi enviada quando não foi.
O que os visitantes veem e o que fica registado
Mantenha curto e simples o que os visitantes veem: se funcionou e, se algo precisar de ser corrigido, uma nota junto a esse campo. Nunca mostre detalhes de erros nem nada sobre a forma como os seus sistemas estão configurados. Nos bastidores, guarde um registo do que aconteceu a cada pedido de contacto, com o respetivo número de referência e o mínimo possível de informação pessoal: sem nomes, sem mensagens, sem endereços de email completos.
Isto é exagero para um formulário de contacto?
A parte extra é pequena: algumas centenas de linhas de código bem testado no seu site, que raramente mudam. Em troca, o seu CRM só contém pedidos de contacto reais, o seu sistema de automação não fica aberto a toda a internet e nenhum pedido se perde durante a manutenção. Se o seu formulário é a forma como a sua empresa consegue trabalho, é uma boa troca.
Se o seu formulário já envia diretamente para o n8n, a mudança costuma ser simples. As verificações são adicionadas ao seu site, o endereço e o segredo do n8n passam para as definições privadas do seu site, o n8n é configurado para verificar a assinatura e o formulário é apontado para o seu site. Se quiser uma segunda opinião, teremos todo o gosto em ver o seu e dizer-lhe o que a mudança implicaria.