Responder a mensagens do WhatsApp com um chatflow do Flowise

Porque é que o Flowise precisa de algo à frente?

Porque o webhook da Meta e a API do Flowise falam formatos diferentes. A Meta valida um destino com um GET que tem de devolver hub.challenge como corpo simples e entrega depois cada mensagem num POST JSON aninhado. A Prediction API do Flowise espera um POST para /api/v1/prediction/ seguido do ID do fluxo, com um campo question. Nenhum dos dois se adapta ao outro, por isso um recetor faz a tradução.

O recetor pode ser um nó Webhook do n8n, uma rota em Python ou Node, ou qualquer função serverless. Responde ao GET de verificação, confere um segredo aleatório e longo colocado no URL do webhook, responde 200 à Meta de imediato e só depois faz o trabalho. O segredo no URL é a autenticação que funciona aqui: a Meta assina as entregas com o app secret do Tech Provider, que nunca é partilhado, pelo que o cabeçalho X-Hub-Signature-256 não pode ser validado do seu lado.

Como deve o recetor chamar a Prediction API?

Com o texto do cliente como question e o número de WhatsApp do cliente como sessão. O Flowise aceita overrideConfig em cada pedido, e um sessionId lá dentro permite que os nós de memória mantenham uma conversa por pessoa, em vez de misturarem todos num único fio. O número do remetente, presente no payload do webhook, é uma chave estável e natural para isso.

Se o chatflow estiver protegido com uma chave de API, o recetor envia-a como bearer token. Defina streaming como false, a menos que o recetor esteja preparado para montar um fluxo contínuo, pois o WhatsApp entrega uma mensagem completa e não um token de cada vez.

A resposta sai como mensagem de texto da Cloud API, a partir do mesmo número. Isso é gratuito e permitido dentro da janela de 24 horas aberta pela mensagem do cliente. Tudo o que o fluxo queira enviar mais tarde, como um lembrete, tem de ser um template aprovado.

POST https://your-flowise-host/api/v1/prediction/<flow-id>
Authorization: Bearer <flowise-api-key>
Content-Type: application/json

{
  "question": "do you have anything friday?",
  "streaming": false,
  "overrideConfig": { "sessionId": "14155550188" }
}

Um agente do Flowise pode usar o servidor MCP da EasyCoexistence?

Hoje não. O Custom MCP do Flowise liga-se a um servidor Streamable HTTP com um URL e um conjunto de cabeçalhos, normalmente um bearer token estático guardado numa variável do Flowise. O servidor MCP da EasyCoexistence autentica-se com OAuth, com início de sessão no navegador e tokens emitidos por si, pelo que não existe uma chave estática para colocar num cabeçalho.

A divisão que funciona é deixar o fluxo decidir e o recetor enviar. O fluxo devolve o texto a dizer, ou o nome de um template quando o cliente esteve em silêncio mais de um dia, e o recetor faz a chamada à Cloud API com o token do número. Assim, o token nunca fica dentro do Flowise, e a regra das 24 horas é aplicada em código, verificando quando o contacto escreveu pela última vez, em vez de ficar entregue a um modelo que pode esquecê-la.

As mensagens recebidas continuam a chegar apenas pelo webhook, seja qual for a forma de envio.

Erros comuns

• Omitir o sessionId. Todos os clientes passam a partilhar a mesma memória, e os dados de uma pessoa podem surgir na resposta a outra.
• Esperar pelo Flowise antes de responder à Meta. Um 200 lento é repetido, e a mesma mensagem é processada duas vezes.
• Deixar o fluxo enviar texto livre um dia depois. Fora da janela, a Meta recusa-o com o erro 131047.

Perguntas frequentes

Continue a ler