Sagutin ang mga mensahe sa WhatsApp gamit ang Flowise chatflow

Bakit kailangan ng Flowise ng ibang bahagi sa harap nito?

Dahil magkaiba ang hugis ng webhook ng Meta at ng API ng Flowise. Bineberipika ng Meta ang destination gamit ang GET na dapat magbalik ng hub.challenge bilang raw body, at saka inihahatid ang bawat mensahe bilang nested JSON POST. Ang Prediction API ng Flowise naman ay umaasa ng POST sa /api/v1/prediction/ na sinusundan ng flow id, na may field na question. Hindi iaangkop ng alinman ang sarili sa isa, kaya isang receiver ang nagsasalin.

Ang receiver ay maaaring n8n Webhook node, isang route sa Python o Node, o anumang serverless function. Sinasagot nito ang verification GET, sinusuri ang mahaba at random na secret na nasa webhook URL, agad na sumasagot ng 200 sa Meta, at saka ginagawa ang trabaho. Ang secret sa URL ang authentication na gumagana rito: pinipirmahan ng Meta ang mga delivery gamit ang app secret ng Tech Provider, na hindi kailanman ibinabahagi, kaya hindi ma-validate sa inyong panig ang X-Hub-Signature-256 header.

Paano dapat tawagin ng receiver ang Prediction API?

Gamitin ang text ng customer bilang question at ang WhatsApp numero ng customer bilang session. Tumatanggap ang Flowise ng overrideConfig sa bawat request, at ang sessionId sa loob nito ang nagpapahintulot sa mga memory node na magtago ng isang usapan kada tao sa halip na paghalu-haluin ang lahat sa iisang thread. Ang numero ng nagpadala mula sa webhook payload ay isang matatag at natural na key para dito.

Kung protektado ng API key ang chatflow, ipinapadala ito ng receiver bilang bearer token. I-set ang streaming sa false maliban kung ang receiver ay ginawang mag-assemble ng stream, dahil ang WhatsApp ay naghahatid ng isang buong mensahe at hindi isang token kada pagkakataon.

Ang sagot ay lalabas bilang Cloud API text na mensahe mula sa parehong numero. Libre ito at pinapayagan sa loob ng 24 oras na window na binuksan ng mensahe ng customer. Anumang nais ipadala ng flow sa ibang pagkakataon, gaya ng paalala, ay kailangang aprubadong template.

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

Magagamit ba ng Flowise agent ang EasyCoexistence MCP server?

Hindi pa sa ngayon. Kumokonekta ang Custom MCP ng Flowise sa isang Streamable HTTP server gamit ang URL at ilang header, karaniwan ay isang static na bearer token na nakatago sa Flowise variable. Ang EasyCoexistence MCP server ay nag-aauthenticate gamit ang OAuth, na may browser sign-in at mga token na ito mismo ang naglalabas, kaya walang static na key na maaaring ilagay sa header.

Ang gumaganang hatian ay hayaang ang flow ang magpasya at ang receiver ang magpadala. Ibinabalik ng flow ang tekstong sasabihin, o ang pangalan ng template kapag higit sa isang araw nang tahimik ang customer, at ang receiver ang gumagawa ng Cloud API call gamit ang token ng numero. Sa gayon, hindi kailanman mapupunta sa loob ng Flowise ang token, at ang 24 oras na patakaran ay ipinapatupad sa code sa pamamagitan ng pagsuri kung kailan huling sumulat ang contact, sa halip na iasa sa isang model na maaaring makalimot.

Ang mga papasok na mensahe ay darating pa rin sa webhook lamang, anuman ang paraan ng pagpapadala.

Mga karaniwang pagkakamali

• Hindi paglalagay ng sessionId. Magbabahagi ang bawat customer ng iisang memory, at maaaring lumabas ang detalye ng isang tao sa sagot para sa iba.
• Paghihintay sa Flowise bago sumagot sa Meta. Uulitin ang mabagal na 200, kaya dalawang beses mapoproseso ang parehong mensahe.
• Pagpapadala ng free-form text ng flow pagkalipas ng isang araw. Sa labas ng window, tinatanggihan ito ng Meta na may error 131047.

Mga madalas itanong

Magpatuloy sa pagbabasa