Trimiteți și primiți WhatsApp din Node.js
Primirea se face printr-o rută care răspunde la GET-ul de verificare Meta și acceptă cereri POST. Trimiterea este un apel fetch către Cloud API, cu ID-ul numărului de telefon și token-ul. Nu există un SDK al nostru și nimic de instalat.
Un GET pentru verificarea Meta și un POST pentru evenimente.
Intervalul de după mesajul unui client în care se poate trimite text liber.
Eroarea returnată când trimiteți text liber în afara acestui interval.
Cum primiți mesaje în Node?
O singură rută cu două metode, în Express, Fastify, un handler de rută Next sau un server simplu.
GET-ul răspunde verificării Meta: citiți hub.mode, hub.verify_token și hub.challenge din parametrii cererii, comparați token-ul cu al dumneavoastră și returnați challenge ca text simplu. Returnarea lui ca JSON este greșeala obișnuită și produce un endpoint care nu primește niciodată nimic, deși pare corect.
POST-ul primește evenimentele. Răspundeți imediat cu 200 și procesați apoi. Meta reîncearcă orice operațiune lentă, iar un handler care își face treaba înainte de răspuns va vedea același mesaj de mai multe ori. În special pe serverless, returnarea răspunsului mai întâi și trimiterea lucrării într-o coadă împiedică transformarea unei porniri la rece într-un duplicat.
Cum trimiteți?
Un apel fetch către endpoint-ul de mesaje Cloud API pentru ID-ul numărului de telefon, cu token-ul într-un antet bearer.
Nimic nu este specific nouă, astfel încât cererea corespunde exact documentației Meta și nu există niciun wrapper de învățat sau de care să depindeți. Ambele valori se află în dashboard, iar get_api_credentials le returnează prin conectorul MCP dacă un asistent face configurarea.
Corpul depinde de momentul trimiterii. În primele 24 de ore de la ultimul mesaj primit de la client, trimiteți un obiect text. După acest interval, trimiteți un obiect template cu un nume de template aprobat și limba. Codul care trimite doar text trece toate testele și eșuează la primul mesaj primit peste noapte.
Ce este diferit pe serverless?
Două lucruri, ambele legate de încheierea funcției înainte de terminarea lucrării.
Returnarea lui 200 și continuarea procesării nu funcționează dacă funcția se blochează în momentul răspunsului. Folosiți ce oferă platforma dumneavoastră pentru a menține lucrarea activă după răspuns sau puneți payload-ul într-o coadă, unde îl va prelucra o funcție separată. Meta are nevoie doar de confirmare rapidă, nu ca lucrarea să fie deja terminată.
Pornirile la rece fac și răspunsurile lente mai probabile, ceea ce înseamnă mai multe reîncercări și duplicate. Deduplicarea după ID-ul mesajului wamid nu este opțională în acest model, ci este ceea ce îl face fiabil.
Greșeli frecvente
- Returnarea challenge ca JSON în locul corpului brut.
- Efectuarea lucrării înainte de răspunsul 200. Pe serverless, funcția se poate bloca în momentul răspunsului.
- Omiterea deduplicării. Meta reîncearcă în mod intenționat, iar duplicatele sunt normale, nu un caz marginal.
Conectați numărul la easycoexistence.com, setați destinația webhook-ului la ruta dumneavoastră și citiți ID-ul numărului de telefon și token-ul din dashboard. De la US$ 9 per număr pe lună, până la US$ 2 la volum, cu primele 7 zile gratuite.
Întrebări frecvente
Am nevoie de o bibliotecă?
Nu. O rută și un apel fetch sunt suficiente, iar apelul corespunde exact documentației Meta.
Funcționează pe Vercel sau Lambda?
Da, cu precauția obișnuită pentru serverless: confirmați mai întâi, apoi procesați printr-o coadă sau un mecanism de fundal, nu inline.
Cum verific că cererea a venit de la Meta?
Verificați antetul semnăturii folosind secretul aplicației. Merită să faceți acest lucru imediat ce endpoint-ul devine public.
Pot folosi TypeScript?
Da. Nu există nimic de tipizat din partea noastră, deoarece payload-ul este al Meta și este documentat de Meta.
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