Invia e ricevi WhatsApp da Node.js
La ricezione avviene tramite una route che risponde al GET di verifica di Meta e accetta i POST. L'invio è una chiamata fetch alla Cloud API con il phone number id e il token del numero. Non esistono SDK nostri e non devi installare nulla.
Un GET per la verifica di Meta e un POST per gli eventi.
La finestra successiva a un messaggio del cliente in cui puoi inviare testo libero.
L'errore restituito quando invii testo libero fuori da quella finestra.
Come ricevi i messaggi in Node?
Una route con due metodi, in Express, Fastify, un gestore di route Next o un server semplice.
Il GET risponde alla verifica di Meta: leggi hub.mode, hub.verify_token e hub.challenge dalla query, confronta il token con il tuo e restituisci la challenge come testo semplice. Restituirla come JSON è l'errore più comune e produce un endpoint che non riceve mai nulla, pur sembrando corretto.
Il POST riceve gli eventi. Rispondi subito con 200 e processa tutto dopo. Meta riprova ogni richiesta lenta e un gestore che svolge il lavoro prima di rispondere vedrà lo stesso messaggio più di una volta. Soprattutto in serverless, restituire prima la risposta e accodare il lavoro evita che un avvio a freddo generi un duplicato.
Come invii?
Una chiamata fetch all'endpoint messages della Cloud API per il phone number id, con il token nell'header bearer.
Non c'è nulla di specifico per noi, quindi la richiesta corrisponde esattamente alla documentazione di Meta e non devi imparare o usare un wrapper vincolante. Entrambi i valori sono nella dashboard e get_api_credentials li restituisce tramite il connettore MCP se un assistente sta configurando l'integrazione.
Il body dipende dal momento dell'invio. Entro 24 ore dall'ultimo messaggio in entrata del cliente, invia un text object. Dopo, invia un template object con un nome e una lingua di template approvati. Il codice che invia solo testo supera ogni test e fallisce al primo messaggio arrivato durante la notte.
Cosa cambia in serverless?
Due cose, entrambe legate al fatto che la funzione può terminare prima del lavoro.
Restituire 200 e continuare a processare non funziona quando una funzione si congela appena risponde. Usa ciò che offre la tua piattaforma per mantenere il lavoro attivo dopo la risposta oppure inserisci il payload in una coda e lascia che lo gestisca una funzione separata. A Meta serve solo una conferma rapida, non che il lavoro sia già terminato.
Gli avvii a freddo rendono più probabili le risposte lente, con più tentativi e duplicati. La deduplicazione sull'ID messaggio wamid non è facoltativa in questo modello: è ciò che lo rende affidabile.
Errori comuni
- Restituire la challenge come JSON invece che come body grezzo.
- Svolgere il lavoro prima di rispondere con 200. In serverless la funzione può congelarsi appena risponde.
- Saltare la deduplicazione. Meta riprova per progettazione e i duplicati sono normali, non un caso limite.
Collega il numero su easycoexistence.com, imposta la destinazione del webhook sulla tua route e leggi phone number id e token dalla dashboard. Da US$ 9 per numero al mese, fino a US$ 2 con i volumi, con i primi 7 giorni gratuiti.
Domande frequenti
Mi serve una libreria?
No. Bastano una route e una fetch, e la chiamata corrisponde esattamente alla documentazione di Meta.
Funziona su Vercel o Lambda?
Sì, con la consueta attenzione del serverless: conferma prima, poi processa tramite una coda o un meccanismo in background, non inline.
Come verifico che la richiesta provenga da Meta?
Controlla l'header della firma usando il segreto della tua app. Conviene farlo appena l'endpoint diventa pubblico.
Posso usare TypeScript?
Sì. Da parte nostra non c'è nulla contro cui tipizzare, perché il payload è di Meta ed è documentato da Meta.
Continua a leggere
Pronto per iniziare?
Configura WhatsApp Coexistence in pochi minuti, non in mesi. L'app continua a funzionare sul telefono.
Inizia la prova gratuitaVerificato il