Responde mensajes de WhatsApp con un chatflow de Flowise

¿Por qué Flowise necesita algo delante?

Porque el webhook de Meta y la API de Flowise hablan formatos distintos. Meta verifica un destino con un GET que debe devolver hub.challenge como cuerpo sin procesar, y luego entrega cada mensaje como un POST con JSON anidado. La Prediction API de Flowise espera un POST a /api/v1/prediction/ seguido del id del flujo, con un campo question. Ninguno de los dos se adapta al otro, así que un receptor hace de traductor.

El receptor puede ser un nodo Webhook de n8n, una ruta en Python o Node, o cualquier función serverless. Responde al GET de verificación, comprueba un secreto largo y aleatorio incluido en la URL del webhook, responde 200 a Meta de inmediato y después hace el trabajo. El secreto en la URL es la autenticación que funciona aquí: Meta firma las entregas con el app secret del Tech Provider, que nunca se comparte, así que el encabezado X-Hub-Signature-256 no se puede validar de tu lado.

¿Cómo debe llamar el receptor a la Prediction API?

Con el texto del cliente como question y el número de WhatsApp del cliente como sesión. Flowise acepta overrideConfig en cada petición, y un sessionId dentro de él es lo que permite que los nodos de memoria mantengan una conversación por persona en lugar de mezclar a todos en un solo hilo. El número del remitente que viene en el payload del webhook es una clave estable y natural para eso.

Si el chatflow está protegido con una API key, el receptor la envía como bearer token. Pon streaming en false, salvo que el receptor esté preparado para ensamblar un stream, ya que WhatsApp entrega un mensaje terminado y no un token a la vez.

La respuesta sale como mensaje de texto de la Cloud API desde el mismo número. Eso es gratis y está permitido dentro de la ventana de atención de 24 horas que abrió el mensaje del cliente. Cualquier cosa que el flujo quiera enviar después, como un recordatorio, tiene que ser una plantilla aprobada.

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" }
}

¿Puede un agente de Flowise usar el servidor MCP de EasyCoexistence?

Hoy no. El Custom MCP de Flowise se conecta a un servidor Streamable HTTP con una URL y un conjunto de encabezados, normalmente un bearer token estático guardado en una variable de Flowise. El servidor MCP de EasyCoexistence se autentica con OAuth, con inicio de sesión en el navegador y tokens que emite él mismo, así que no hay una clave estática que poner en un encabezado.

La división que funciona es dejar que el flujo decida y que el receptor envíe. El flujo devuelve el texto que hay que decir, o el nombre de una plantilla cuando el cliente lleva más de un día en silencio, y el receptor hace la llamada a la Cloud API con el token del número. Así el token nunca queda dentro de Flowise, y la regla de las 24 horas se aplica en código, comprobando cuándo escribió el contacto por última vez, en lugar de dejarla en manos de un modelo que puede olvidarla.

Los mensajes entrantes siguen llegando solo por el webhook, sea cual sea la forma de enviar.

Errores comunes

• Omitir sessionId. Entonces todos los clientes comparten una sola memoria, y los datos de una persona pueden aparecer en la respuesta a otra.
• Esperar a Flowise antes de responder a Meta. Un 200 lento se reintenta, y el mismo mensaje se procesa dos veces.
• Dejar que el flujo envíe texto libre un día después. Fuera de la ventana, Meta lo rechaza con el error 131047.

Preguntas frecuentes

Sigue leyendo