Sagutin ang mga mensahe sa WhatsApp gamit ang Dify app

Maaari bang direktang magpadala ang Meta ng mga mensahe sa WhatsApp papunta sa Dify?

Hindi sa paraang makukumpleto ang handshake. Bago maghatid ng anuman, tinatawag muna ng Meta ang destinasyon gamit ang GET at inaasahang maibabalik ang halaga ng hub.challenge bilang raw na response body. Ang Webhook Trigger ng Dify ay tumatanggap lamang ng isang HTTP method kada trigger, at ayon sa dokumentasyon nito, awtomatikong kino-convert sa JSON ang response body na hindi JSON, kaya ang OK ay bumabalik bilang isang message object. Hindi kailanman maibabalik nang eksakto ang challenge, at hindi kailanman magsisimulang maghatid ang Meta.

Kaya may maliit na bahagi na dapat ilagay sa harap. Maaaring isang n8n Webhook node, isang route sa Python o Node, o isang serverless function ang sasagot sa GET, tatanggap ng POST, at magpapasa ng teksto sa Dify. Sa receiver ding iyon sinusuri ang mahaba at random na secret sa webhook URL, dahil ang header na X-Hub-Signature-256 ay pinirmahan gamit ang app secret ng Tech Provider at hindi ito mave-validate ng customer.

Paano nakikipag-usap ang receiver sa Dify app?

Sa isang tawag lamang sa Service API ng Dify: POST /chat-messages, na may authentication gamit ang API key ng app. Dala ng body ang query, ang teksto ng customer, at ang user, isang identifier na kayo ang magtatakda. Gamitin po ninyo ang numero ng WhatsApp ng nagpadala bilang user, at itago ang conversation_id na ibinabalik ng Dify upang ang susunod na mensahe mula sa parehong tao ay magpatuloy sa parehong usapan.

Mahalaga ang response_mode. Ang blocking ay bumabalik kapag kumpleto na ang sagot, at nagbababala ang dokumentasyon ng Dify na sa Dify Cloud, maaaring maputol ng edge proxy ang mahabang generation. Streaming lamang ang sinusuportahan ng mga Agent app, at nabibigo ang blocking request sa mga ito na may 400. Ang receiver na bumabasa ng stream at nagpapadala ng isang mensahe sa WhatsApp sa dulo ang pinaka-maaasahang anyo.

Pagkatapos, lalabas ang sagot bilang text na mensahe ng Cloud API papunta sa parehong numero, na libre sa loob ng 24 oras na window na binuksan ng mensahe ng customer.

Ano ang idinadagdag ng MCP server sa loob ng Dify?

Ang kakayahan ng isang Dify agent na kumilos sa numero nang hindi ninyo kailangang i-wire ang bawat tawag. Kumokonekta ang Dify sa mga MCP server sa pamamagitan ng HTTP at, bilang default, nagpaparehistro ito sa server gamit ang OAuth dynamic client registration, na sinusuportahan ng EasyCoexistence MCP server. Idagdag po ito sa ilalim ng Tools, mag-sign in nang isang beses, at makukuha ng agent ang mga tool: ilista ang mga numero, suriin ang kalusugan ng numero, magpadala ng mensahe, magpadala ng aprubadong template, basahin ang status ng template.

Iyon ang tamang lugar para sa proactive na gawain: ang isang Dify workflow na nagfo-follow up kinabukasan ay kailangang gumamit ng send_template, dahil ang free-form text sa labas ng window ay nagbabalik ng error 131047, at sinasabi ito ng mga paglalarawan ng tool sa model.

Ang hindi kayang gawin ng MCP ay gisingin ang Dify kapag sumulat ang customer. Request at sagot ang protocol, kaya ang mga papasok na mensahe ay darating pa rin sa pamamagitan ng webhook at ng receiver sa harap.

Mga karaniwang pagkakamali

• Paggamit ng URL ng Dify Webhook Trigger bilang destinasyon ng webhook. Bumabalik ang challenge na nakabalot sa JSON at hindi kailanman nave-verify ng Meta ang endpoint.
• Pagpapadala ng blocking request sa isang Dify Agent app. Streaming lamang ang sinusuportahan ng mga Agent app, at nabibigo ang tawag na may 400.
• Paggamit ng bagong halaga ng user sa bawat mensahe. Nakasaklaw ang mga usapan ng Dify sa user, kaya bawat mensahe ay nagsisimula ng bagong usapan na walang alaala.

Mga madalas itanong

Magpatuloy sa pagbabasa