WhatsApp-berichten verzenden en ontvangen vanuit Node.js
Ontvangen gebeurt via een route die Meta's verificatie-GET beantwoordt en POST's accepteert. Verzenden gebeurt met een fetch-aanroep naar de Cloud API, met de phone number id en het token van het nummer. We hebben geen SDK en je hoeft niets te installeren.
Een GET voor Meta's verificatie en een POST voor gebeurtenissen.
Het venster na een klantbericht waarin je vrije tekst kunt verzenden.
De fout die je krijgt wanneer je vrije tekst buiten dat venster verzendt.
Hoe ontvang je berichten in Node?
Eén route met twee methoden, in Express, Fastify, een Next route handler of een gewone server.
De GET beantwoordt Meta's verificatie: lees hub.mode, hub.verify_token en hub.challenge uit de query, vergelijk het token met dat van jou en geef de challenge als platte tekst terug. Deze als JSON teruggeven is de gebruikelijke fout. Dan ontvang je nooit iets, hoewel het endpoint er correct uitziet.
De POST ontvangt gebeurtenissen. Antwoord direct met 200 en verwerk daarna. Meta probeert trage verzoeken opnieuw, en een handler die eerst werk uitvoert, ziet hetzelfde bericht meer dan één keer. Vooral bij serverless voorkomt eerst antwoorden en het werk daarna in een wachtrij zetten dat een cold start tot duplicaten leidt.
Hoe verzend je?
Een fetch-aanroep naar het messages-endpoint van de Cloud API voor de phone number id, met het token als bearer-header.
Niets hieraan is specifiek voor ons. Het verzoek volgt dus precies Meta's eigen documentatie en je leert geen wrapper die je later niet meer kunt vervangen. Beide waarden staan in het dashboard, en get_api_credentials geeft ze via de MCP-connector terug als een assistent de koppeling instelt.
De body hangt af van de timing. Binnen 24 uur na het laatste inkomende bericht van de klant stuur je een text-object. Daarna stuur je een template-object met een goedgekeurde templ naam en taal. Code die alleen tekst verzendt, slaagt voor elke test en faalt bij het eerste bericht dat 's nachts binnenkomt.
Wat is anders bij serverless?
Twee dingen, en beide gaan erover dat de functie eindigt voordat het werk klaar is.
Een antwoord met 200 teruggeven en daarna doorgaan met verwerken werkt niet wanneer een functie bevriest zodra ze antwoordt. Gebruik wat je platform biedt om werk na het antwoord actief te houden, of zet de payload op een wachtrij en laat een aparte functie die verwerken. Meta heeft alleen snel een bevestiging nodig, niet het uitgevoerde werk.
Cold starts maken trage antwoorden waarschijnlijker, wat meer nieuwe pogingen en duplicaten betekent. Dedupliceren op de wamid-bericht-id is in deze opzet verplicht. Dat maakt de verwerking betrouwbaar.
Veelgemaakte fouten
- De challenge als JSON teruggeven in plaats van als onbewerkte body.
- Het werk uitvoeren voordat je 200 teruggeeft. Bij serverless kan de functie bevriezen zodra ze antwoordt.
- Deduplicatie overslaan. Meta probeert standaard opnieuw en duplicaten zijn normaal, geen uitzonderingsgeval.
Verbind het nummer via easycoexistence.com, stel de webhook-bestemming in op je route en lees de phone number id en het token uit het dashboard. Vanaf US$ 9 per nummer per maand, dalend naar US$ 2 bij volume, met de eerste 7 dagen gratis.
Veelgestelde vragen
Heb ik een bibliotheek nodig?
Nee. Een route en fetch zijn genoeg, en de aanroep volgt precies Meta's documentatie.
Werkt dit op Vercel of Lambda?
Ja, met de gebruikelijke kanttekening bij serverless: bevestig eerst en verwerk daarna via een wachtrij of achtergrondmechanisme, niet inline.
Hoe verifieer ik dat het verzoek van Meta kwam?
Controleer de signature-header met je app-secret. Doe dit zodra het endpoint openbaar is.
Kan ik TypeScript gebruiken?
Ja. Van onze kant hoef je niets te typeren, want de payload is van Meta en door Meta gedocumenteerd.
Lees verder
Klaar om te beginnen?
Stel WhatsApp Coexistence in enkele minuten in, niet maanden. De app blijft op je telefoon werken.
Start je gratis proefperiodeGeverifieerd op