Responda mensagens do WhatsApp com um app do Dify

A Meta pode enviar mensagens do WhatsApp direto para o Dify?

Não de um jeito que complete o handshake. Antes de entregar qualquer coisa, a Meta chama o destino com um GET e espera receber o valor de hub.challenge de volta como corpo bruto da resposta. O Webhook Trigger do Dify aceita um método HTTP por trigger, e a documentação dele diz que um corpo de resposta que não seja JSON é convertido automaticamente em JSON, então OK volta como um objeto de mensagem. O challenge nunca pode ser devolvido exatamente, e a Meta nunca começa a entregar.

Por isso, algo pequeno fica na frente. Um nó Webhook do n8n, uma rota em Python ou Node, ou uma função serverless responde ao GET, aceita o POST e repassa o texto ao Dify. Esse receptor também é onde se confere o segredo longo e aleatório na URL do webhook, já que o cabeçalho X-Hub-Signature-256 é assinado com o app secret do Tech Provider e não pode ser validado pelo cliente.

Como o receptor conversa com o app do Dify?

Com uma chamada à Service API do Dify: POST /chat-messages, autenticada com a chave de API do app. O corpo leva query, o texto do cliente, e user, um identificador que você define. Use o número de WhatsApp de quem enviou como user e guarde o conversation_id que o Dify devolve, para que a próxima mensagem da mesma pessoa continue a mesma conversa.

O response_mode importa. O modo blocking responde quando a resposta está completa, e a documentação do Dify avisa que, no Dify Cloud, uma geração longa pode ser cortada pelo proxy de borda. Apps do tipo Agent aceitam apenas streaming, e uma requisição blocking a eles falha com 400. Um receptor que lê o stream e envia uma única mensagem de WhatsApp no final é o formato robusto.

A resposta então sai como mensagem de texto da Cloud API para o mesmo número, o que é gratuito dentro da janela de atendimento de 24 horas aberta pela mensagem do cliente.

O que o servidor MCP acrescenta dentro do Dify?

A capacidade de um agente do Dify atuar no número sem que você precise ligar cada chamada. O Dify se conecta a servidores MCP por HTTP e, por padrão, se registra no servidor por registro dinâmico de cliente OAuth, que é o que o servidor MCP da EasyCoexistence suporta. Adicione-o em Tools, entre uma vez, e o agente recebe as ferramentas: listar os números, verificar a saúde de um número, enviar uma mensagem, enviar um template aprovado, ler o status de um template de mensagem.

Esse é o lugar certo para o trabalho proativo: um workflow do Dify que faz o acompanhamento no dia seguinte precisa usar send_template, porque texto livre fora da janela devolve o erro 131047, e as descrições das ferramentas avisam o modelo disso.

O que o MCP não consegue fazer é acordar o Dify quando um cliente escreve. O protocolo é de requisição e resposta, então as mensagens recebidas continuam chegando pelo webhook e pelo receptor na frente.

Erros comuns

• Usar a URL de um Webhook Trigger do Dify como destino do webhook. O challenge volta embrulhado em JSON e a Meta nunca verifica o endpoint.
• Enviar uma requisição blocking a um app Agent do Dify. Apps Agent aceitam apenas streaming, e a chamada falha com 400.
• Usar um valor de user novo a cada mensagem. O Dify delimita as conversas por user, então cada mensagem inicia uma conversa nova, sem memória.

Perguntas frequentes

Continue lendo