WhatsApp webhooks: direktang pagruruta ng mga mensahe sa inyong server

Ano talaga ang ipinapadala ng Meta sa isang webhook?

Mga event ito na nasa iba’t ibang category, at ang pagkakaiba ng mga ito ang nagtatakda ng architecture ninyo.

Dala ng path ng mensahe ang ipinapadala ng mga customer at, sa naka-connect na numero ng Coexistence, ang mga echo ng ipinapadala ng inyong team mula sa WhatsApp Business app. Ang mga field na ito ay messages at smb_message_echoes, at dito nakalagay ang laman ng pag-uusap.

Dala ng operational path ang lahat ng iba pa: account_update kapag nagbago ang estado ng koneksyon, phone_number_quality_update kapag nagbago ang quality o throughput, account_alerts, account_review_update, business_capability_update at phone_number_name_update. Walang laman na pag-uusap ang mga ito at dito binubuo ang pagmo-monitor.

Ang provider na naglalagay sa sarili nito sa path ng mensahe ay tumatanggap ng unang grupo. Ang hindi gumagawa nito ay hindi tumatanggap.

Paano bini-verify ng Meta ang isang endpoint?

Sa pamamagitan ng GET request bago ito mag-deliver ng anuman, at ang pagkabigo rito ang pinakakaraniwang dahilan kung bakit hindi nakakatanggap ng mensahe ang setup na mukhang tapos na.

Tinatawag ng Meta ang inyong URL na may hub.mode na nakatakda sa subscribe, inyong hub.verify_token at value na hub.challenge. Kailangang ibalik ng inyong endpoint ang challenge bilang raw response body, hindi naka-wrap sa JSON at walang idinagdag. Kung hindi, hindi magsisimulang mag-deliver ang Meta, at walang dashboard na magsasabi nito.

HTTPS din dapat ang endpoint. Ang endpoint na nagbabalik ng tahimik na 404, o nasa likod ng authentication layer na nagre-reject sa Meta, ay mukhang gumaganang setup hanggang sa hindi dumating ang unang mensahe.

Maaari bang ituro ang destinasyon sa sarili ninyong server?

Oo, at ito ang bahagi na naiiba sa bawat provider.

Pinapayagan ng Meta ang isang app na i-override kung saan ihahatid ng isang WhatsApp Business Account ang mga webhook nito. Itinatakda namin ang override na iyon sa inyong URL, kaya inililipat ang mga event sa path ng mensahe mula sa aming callback papunta sa inyo. Pinananatili namin ang operational events dahil dito binubuo ang dashboard at alerting.

Architecture ang epekto nito, hindi isang policy na inilalathala namin. Walang mapaglalagyan sa aming side ang laman ng pag-uusap dahil hindi ito kailanman ihinahatid sa amin. Ang account na walang nakatakdang override ay bumabalik sa aming default callback, kung saan dini-drop ng handler ang mga event nang hindi sine-save.

Ano ang nangyayari sa destinasyon kapag muling kumonekta ang isang numero?

Inaalis ito, at ito ang failure na halos walang naghahanda.

Hindi property ng numero ng telepono ang destinasyon. Isa itong override sa subscription ng aming app sa WhatsApp Business Account. Kapag inalis ang koneksyon, dahil sa fourteen day inactivity rule ng Meta o sa ibang dahilan, ina-uninstall ang app mula sa account at kasama nitong nawawala ang override.

Ibinabalik ng muling pagkonekta ang pagpapadala at pagmo-monitor. Hindi nito ibinabalik ang delivery sa inyong server, at walang nagre-report ng error, kaya ang unang senyales ay customer na nagsasabing walang sumagot. Muli naming ina-apply ang override sa bawat reconnection dahil nangyari ito sa isang totoong numero na malinis na muling kumonekta pero nanahimik.

Mga karaniwang pagkakamali

• Nagbabalik ng JSON mula sa verification GET. Raw na hub.challenge value lang at wala nang iba ang gusto ng Meta.
• Gumagamit ng temporary o test URL. Patuloy itong dinadalhan ng Meta kahit huminto nang makinig ang tool na gumawa nito.
• Ipinapalagay na nananatili ang destinasyon pagkatapos ng reconnection. Nasa app subscription ito at ina-uninstall kasama nito.
• Inilalagay ang endpoint sa likod ng authentication na nagre-reject sa request ng Meta.

Mga madalas itanong

Magpatuloy sa pagbabasa