Responder a mensagens do WhatsApp com uma app Dify

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

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

Por isso, coloca-se algo pequeno à frente. Um nó Webhook do n8n, uma rota em Python ou Node, ou uma função serverless responde ao GET, aceita o POST e passa o texto ao Dify. É também nesse recetor que se verifica o segredo aleatório longo presente no URL do webhook, uma vez que o cabeçalho X-Hub-Signature-256 é assinado com o segredo da app do Tech Provider e não pode ser validado pelo cliente.

Como fala o recetor com a app Dify?

Com uma única chamada à Service API do Dify: POST /chat-messages, autenticado com a chave de API da app. O corpo leva query, o texto do cliente, e user, um identificador definido por si. Use o número de WhatsApp do remetente como user e guarde o conversation_id devolvido pelo Dify, para que a mensagem seguinte da mesma pessoa continue a mesma conversa.

O response_mode é importante. O modo blocking só devolve 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 entrada. As apps de agente suportam apenas streaming e um pedido blocking a uma delas falha com 400. Um recetor que lê o stream e envia uma só mensagem de WhatsApp no fim é a solução mais robusta.

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

O que acrescenta o servidor MCP dentro do Dify?

Permite que um agente do Dify atue no número sem que seja preciso ligar cada chamada à mão. O Dify liga-se a servidores MCP por HTTP e, por predefinição, regista-se no servidor através do registo dinâmico de clientes OAuth, que o servidor MCP da EasyCoexistence suporta. Adicione-o em Ferramentas, inicie sessão uma vez e o agente fica com as ferramentas: listar os números, verificar o estado de um número, enviar uma mensagem, enviar um template aprovado, ler o estado de um template.

É o sítio certo para o trabalho proativo: um fluxo do Dify que faz o acompanhamento no dia seguinte tem de usar send_template, porque texto livre fora da janela devolve o erro 131047, e as descrições das ferramentas dizem-no ao modelo.

O que o MCP não consegue fazer é acordar o Dify quando um cliente escreve. O protocolo funciona por pedido e resposta, por isso as mensagens recebidas continuam a chegar pelo webhook e pelo recetor que está à frente.

Erros comuns

• Usar o URL de um Webhook Trigger do Dify como destino do webhook. O challenge volta envolvido em JSON e a Meta nunca verifica o endpoint.
• Enviar um pedido blocking a uma app Agent do Dify. As apps Agent suportam apenas streaming e a chamada falha com 400.
• Usar um valor user novo por mensagem. O Dify associa as conversas a user, pelo que cada mensagem inicia uma conversa nova, sem memória.

Perguntas frequentes

Continue a ler