Pag-verify ng WhatsApp webhook endpoint
Bago maghatid ng anumang event, tinatawagan ng Meta ang endpoint ninyo gamit ang GET na may hub.mode, hub.verify_token at hub.challenge. Kailangang ikumpara ng endpoint ninyo ang token at ibalik ang challenge bilang raw body. Kapag iba ang sagot, hindi magsisimula ang delivery.
Ang value na kailangang ibalik bilang response body.
Ang value ng hub.mode sa verification request.
Ang tanging scheme na ive-verify ng Meta. Tinatanggihan ang HTTP bago ang call.
Ano mismo ang ipinapadala ng Meta?
Isang GET request sa URL ninyo na may tatlong query parameter. Naka-set sa subscribe ang hub.mode. Ang hub.verify_token ay token na itinakda ninyo nang i-set up ang destination. Ang hub.challenge ay value na ginagawa ng Meta para sa pagtatangkang ito.
Dapat ikumpara ng endpoint ninyo ang hub.verify_token sa token na pinili ninyo. Kapag tugma, magbalik ng 200 na ang hub.challenge ang buong response body. Huwag itong balutin sa JSON, lagyan ng quotes, o sundan ng trailing newline na awtomatikong idinadagdag ng ilang framework.
Kapag hindi tugma ang token, magbalik ng 403. Iyon ang buong protocol, at sinadya itong maging simple.
Bakit tahimik na nagfa-fail ang maling sagot?
Dahil ang pagkabigo ng verification ay hindi error sa system ninyo, kundi kawalan sa system ng Meta.
Kapag hindi naibalik nang tama ang challenge, hindi lang sinisimulan ng Meta ang delivery sa destination na iyon. Nagbabalik ang server ninyo ng 200 sa verification, makikita sa logs ninyo na may dumating na request, at walang dashboard na mag-uulat ng problema. Ang tanging palatandaan ay hindi dumarating ang mga mensahe, kaya karaniwang napagkakamalan itong problema sa Coexistence, hindi sa handshake.
Kaya mahalagang mag-validate bago ang call. Chine-check namin kung HTTPS ang URL at kung may ibinigay na verify token bago gawin ang Graph request, kaya agad na bumabagsak ang maling destination sa halip na magmukhang connected.
Ano pa ang maaaring humarang sa verification?
Tatlong bagay na walang kinalaman sa code.
Authentication sa harap ng endpoint. Tatanggihan ng gateway, basic auth layer, o IP allowlist ang request ng Meta, at walang credentials na maipapakita ang Meta. Kailangang maabot ang verification route nang wala ang mga ito.
Isang redirect. Tinatawagan ng Meta ang URL na ibinigay ninyo, at hindi sinusundan ang 301 papunta sa canonical host sa paraang makukumpleto ang handshake. Ibigay ang final URL.
At isang framework na nagse-serialize ng response. Kapag nagbalik ang handler ng string na binabalot sa JSON ang lahat, magkakaroon ng quotes sa paligid ng challenge, kaya hindi ito magtutugma.
Mga karaniwang pagkakamali
- Pagbabalik ng JSON. Kailangang raw challenge value ang body, na walang nakapaligid dito.
- Paglalagay ng endpoint sa likod ng authentication. Walang credentials ang Meta kaya tatanggihan ito.
- Pagbibigay sa Meta ng URL na nagre-redirect. Gamitin ang final URL.
Bine-validate ng EasyCoexistence na HTTPS ang destination at may verify token bago tawagan ang Meta, at itinatala ang nabigong handshake sa connection timeline sa halip na itapon ang destination.
Mga madalas itanong
Anong token ang dapat gamitin?
Anumang string na piliin ninyo. Ginagamit ito para makilala ng endpoint ninyo ang request ng Meta mula sa request ng ibang nakakaalam ng URL.
Gaano kadalas ginagawa ang verification?
Sa setup, at muli sa tuwing sine-set ang destination. Hindi nire-re-verify ang gumaganang endpoint sa bawat event.
Maaari ko ba itong i-test mismo?
Oo. Tawagan ang sarili ninyong endpoint gamit ang tatlong parameter at tingnan kung ang body ay eksaktong bumabalik bilang challenge value.
Paano kung down ang server ko habang nagve-verify?
Mafi-fail ang handshake at hindi maa-activate ang destination. Kapag sine-save itong muli, tatakbo ulit ang verification.
Magpatuloy sa pagbabasa
Handa na po ba kayong magsimula?
I-set up ang WhatsApp Coexistence sa loob ng ilang minuto, hindi buwan. Patuloy na gumagana ang app sa telepono.
Magsimula ng Libreng TrialNa-verify noong