Kirim dan terima WhatsApp dari Node.js

Bagaimana cara menerima pesan di Node?

Satu rute dengan dua metode, di Express, Fastify, route handler Next, atau server biasa.

GET menjawab verifikasi Meta: baca hub.mode, hub.verify_token, dan hub.challenge dari query, bandingkan token dengan milik Anda, lalu kembalikan challenge sebagai teks biasa. Mengembalikannya sebagai JSON adalah kesalahan yang umum dan menghasilkan endpoint yang tidak pernah menerima apa pun meski terlihat benar.

POST menerima event. Berikan respons 200 segera dan proses setelahnya. Meta akan mencoba kembali apa pun yang lambat, dan handler yang menyelesaikan pekerjaannya sebelum memberi respons akan melihat pesan yang sama lebih dari sekali. Khususnya pada serverless, mengembalikan respons terlebih dahulu lalu memasukkan pekerjaan ke queue membuat cold start tidak berubah menjadi duplikasi.

Bagaimana cara mengirim pesan?

Lakukan fetch ke endpoint messages Cloud API untuk phone_number_id, dengan token sebagai bearer header.

Tidak ada bagian yang khusus untuk kami, sehingga permintaan ini sama persis dengan dokumentasi Meta dan tidak ada wrapper yang perlu dipelajari atau membuat Anda terkunci. Kedua nilai tersebut ada di dashboard, dan get_api_credentials mengembalikannya melalui konektor MCP jika asisten yang melakukan pengaturannya.

Body bergantung pada waktu pengiriman. Dalam 24 jam sejak pesan masuk terakhir dari pelanggan, kirim objek teks. Di luar jangka waktu itu, kirim objek template dengan nama template dan bahasa yang telah disetujui. Kode yang hanya mengirim teks akan lolos semua pengujian dan gagal pada pesan pertama yang masuk semalaman.

Apa yang berbeda pada serverless?

Ada dua hal, dan keduanya berkaitan dengan fungsi yang berakhir sebelum pekerjaannya selesai.

Mengembalikan 200 lalu melanjutkan pemrosesan tidak akan bertahan pada fungsi yang membeku segera setelah memberi respons. Gunakan apa pun yang disediakan platform Anda untuk menjaga pekerjaan tetap berjalan setelah respons, atau masukkan payload ke queue dan biarkan fungsi terpisah menanganinya. Meta hanya membutuhkan pengakuan dengan cepat, bukan pekerjaan tersebut sudah selesai.

Cold start juga membuat respons lambat lebih mungkin terjadi, yang berarti lebih banyak percobaan ulang dan duplikasi. Deduplicasi berdasarkan ID pesan wamid bukan pilihan dalam bentuk ini, melainkan hal yang membuatnya andal.

Kesalahan umum

• Mengembalikan challenge sebagai JSON, bukan sebagai body mentah.
• Mengerjakan proses sebelum memberi respons 200. Pada serverless, fungsi dapat membeku segera setelah memberi respons.
• Melewati deduplicasi. Meta memang mencoba kembali dan duplikasi adalah hal normal, bukan kasus yang jarang terjadi.

Pertanyaan yang sering diajukan

Lanjut membaca