Verificarea unui endpoint webhook WhatsApp
Înainte de a livra orice eveniment, Meta apelează endpoint-ul cu un GET care conține hub.mode, hub.verify_token și hub.challenge. Endpoint-ul trebuie să compare token-ul și să returneze challenge-ul ca body brut. Orice altceva împiedică începerea livrării.
Valoarea care trebuie returnată în corpul răspunsului.
Valoarea lui hub.mode într-o cerere de verificare.
Singura schemă pe care Meta o verifică. HTTP este respins înainte de apel.
Ce trimite exact Meta?
O cerere GET către URL-ul dumneavoastră, cu trei parametri de interogare. hub.mode este setat la subscribe. hub.verify_token este token-ul configurat când ați setat destinația. hub.challenge este o valoare generată de Meta pentru această încercare.
Endpoint-ul trebuie să compare hub.verify_token cu token-ul ales de dumneavoastră și, dacă se potrivesc, să răspundă cu 200, având hub.challenge drept întreg corp al răspunsului. Nu îl încadrați în JSON, nu puneți ghilimele în jurul lui și nu adăugați un rând nou la final, așa cum fac unele framework-uri în mod implicit.
Dacă token-urile nu se potrivesc, răspundeți cu 403. Acesta este întregul protocol și este intenționat simplu.
De ce un răspuns greșit eșuează fără semnal?
Pentru că eșecul verificării nu este o eroare în sistemul dumneavoastră, ci o absență în sistemul Meta.
Când challenge-ul nu este returnat corect, Meta pur și simplu nu începe livrarea către acea destinație. Serverul dumneavoastră răspunde cu 200 la verificare, jurnalele arată că a sosit o cerere, iar niciun dashboard nu raportează o problemă. Singurul simptom este că mesajele nu mai sosesc, lucru diagnosticat de obicei drept o problemă de Coexistence, nu de verificare.
De aceea merită să validați înainte de apel. Verificăm dacă URL-ul folosește HTTPS și dacă a fost furnizat un token de verificare înainte de cererea Graph, astfel încât o destinație incorectă să eșueze imediat, în loc să pară conectată.
Ce altceva poate bloca verificarea?
Trei lucruri care nu au legătură cu codul.
Autentificarea în fața endpoint-ului. Un gateway, un nivel de autentificare de bază sau o listă de IP-uri permise va respinge cererea Meta, iar Meta nu are acreditări de prezentat. Ruta de verificare trebuie să fie accesibilă fără acestea.
O redirecționare. Meta apelează URL-ul furnizat, iar o redirecționare 301 către o gazdă canonică nu este urmată într-un mod care finalizează verificarea. Furnizați URL-ul final.
Și un framework care serializează răspunsul. Returnarea unui șir de caractere dintr-un handler care încadrează totul în JSON produce un corp cu ghilimele în jurul challenge-ului, ceea ce nu corespunde.
Greșeli frecvente
- Returnarea în JSON. Corpul trebuie să fie valoarea brută a challenge-ului, fără nimic în jur.
- Plasarea endpoint-ului în spatele autentificării. Meta nu are acreditări și va fi respinsă.
- Furnizarea unui URL care redirecționează. Folosiți URL-ul final.
EasyCoexistence verifică dacă o destinație folosește HTTPS și are un token de verificare înainte de apelarea Meta și înregistrează o verificare eșuată în cronologia conexiunii, în loc să elimine destinația.
Întrebări frecvente
Ce token ar trebui să folosesc?
Orice șir de caractere ales de dumneavoastră. El permite endpoint-ului să distingă cererea Meta de cererea oricui află URL-ul.
Cât de des are loc verificarea?
La configurare și din nou ori de câte ori este setată destinația. Un endpoint funcțional nu este verificat din nou la fiecare eveniment.
Îl pot testa singur?
Da. Apelați propriul endpoint cu cei trei parametri și verificați dacă body-ul revine exact ca valoarea challenge-ului.
Ce se întâmplă dacă serverul meu era oprit în timpul verificării?
Verificarea eșuează, iar destinația nu se activează. Salvarea ei din nou reia verificarea.
Continuați să citiți
Gata să începeți?
Configurați WhatsApp Coexistence în câteva minute, nu luni. Aplicația continuă să funcționeze pe telefon.
Începeți perioada de probă gratuităVerificat la