Ringkasan singkat
- Integrasi WhatsApp dengan aplikasi internal berarti aplikasi Anda mengirim pesan WhatsApp sendiri, menerima balasan pelanggan, dan mencatat status pengiriman, semuanya terhubung ke data pesanan, pasien, atau tagihan. Staf tidak lagi menyalin informasi bolak-balik antara aplikasi dan WhatsApp.
- Ada tiga aliran data: aplikasi ke WhatsApp (pesan keluar), WhatsApp ke aplikasi (pesan masuk lewat webhook), dan status pengiriman kembali ke aplikasi. Integrasi yang baru menjalankan satu arah biasanya berhenti sebagai notifikasi saja.
- Webhook WhatsApp punya aturan yang memengaruhi rancangan: endpoint harus membalas 200, pengiriman gagal diulang Meta hingga 7 hari sehingga duplikat bisa terjadi, dan tidak ada API untuk mengambil riwayat webhook. Aplikasi perlu menyimpan payload dan menyaring duplikat sendiri.
- Bagian tersulit bukan mengirim pesan, melainkan mencocokkan nomor WhatsApp dengan data yang benar di aplikasi, menangani status yang datang tidak berurutan, dan menjaga data pribadi pelanggan atau pasien.
- Pilihan membangun ada tiga: inbox dari penyedia resmi, alur low-code seperti n8n, atau integrasi langsung ke aplikasi custom. Semakin banyak aturan bisnis dan data sensitif, semakin masuk akal integrasi langsung.
Integrasi WhatsApp dengan aplikasi internal adalah sambungan antara aplikasi perusahaan Anda dan WhatsApp Business Platform, sehingga pesan keluar dibuat dari data aplikasi, pesan masuk dari pelanggan tercatat di aplikasi, dan status pengiriman ikut tersimpan. Hasilnya, staf bekerja dari satu tempat dan pelanggan tetap berkomunikasi lewat WhatsApp yang sudah biasa mereka pakai.
Artikel ini menjelaskan tiga aliran data dalam integrasi, cara kerja webhook WhatsApp, tiga contoh alur (pesanan, pasien, dan tagihan), cara mencocokkan nomor WhatsApp dengan data pelanggan, keamanan dan privasi data, pilihan cara membangunnya, serta komponen biaya. Contoh alur dan hitungan di sini adalah ilustrasi, bukan hasil klien. Aturan teknis Meta kami cek ke dokumentasi resminya pada 31 Oktober 2026 dan bisa berubah.
Apa yang dimaksud integrasi WhatsApp dengan aplikasi internal?
Integrasi WhatsApp berarti aplikasi Anda berbicara langsung dengan WhatsApp Business Platform lewat API, bukan staf yang memindahkan informasi secara manual. Aplikasi yang sudah terhubung dengan WhatsApp bisa mengirim notifikasi, menerima balasan, dan memperbarui data tanpa orang menyalin teks dari satu layar ke layar lain.
| Aspek | Tanpa integrasi (manual) | Dengan integrasi ke aplikasi |
|---|---|---|
| Sumber isi pesan | Staf mengetik atau menyalin dari aplikasi | Template terisi otomatis dari data pesanan, pasien, atau tagihan |
| Pesan masuk dari pelanggan | Tersebar di ponsel staf atau inbox yang terpisah dari aplikasi | Tercatat di aplikasi dan terhubung ke pelanggan serta transaksinya |
| Status pesan | Dilihat manual di chat, sering terlewat | Terkirim, sampai, dibaca, atau gagal tersimpan di aplikasi |
| Tindak lanjut | Staf mengingat sendiri siapa yang perlu dihubungi | Aplikasi membuat tugas atau mengubah status otomatis dari balasan |
| Jejak audit | Sulit dilacak siapa mengirim apa kapan | Setiap pesan dan balasan punya catatan waktu dan penanggung jawab |
Integrasi ini berbeda dari notifikasi biasa. Artikel notifikasi WhatsApp otomatis membahas pesan keluar saja, sedangkan integrasi mencakup juga pesan masuk dan status, sehingga aplikasi menjadi pusat percakapan yang terstruktur. Untuk perbandingan dengan aplikasi WhatsApp Business biasa, lihat artikel WhatsApp Business App vs WhatsApp API.
Tiga aliran data dalam aplikasi yang terhubung WhatsApp
Hampir semua integrasi WhatsApp bisa dipahami sebagai tiga aliran data. Memisahkannya membantu menentukan apa yang perlu dibangun lebih dulu dan apa yang bisa menyusul.
| Aliran | Arah | Mekanisme | Contoh | Yang perlu disimpan di aplikasi |
|---|---|---|---|---|
| Pesan keluar | Aplikasi ke WhatsApp | Aplikasi memanggil API pengiriman dengan template dan data | Pengingat jadwal, invoice, status pesanan | ID pesan dari respons, kapan dikirim, template yang dipakai |
| Pesan masuk | WhatsApp ke aplikasi | Webhook: Meta mengirim POST ke alamat aplikasi Anda | Pelanggan membalas 'Konfirmasi' atau bertanya status | Isi pesan, nomor pengirim, waktu, ID pesan |
| Status pengiriman | WhatsApp ke aplikasi | Webhook status untuk pesan yang pernah Anda kirim | Pesan terkirim, sampai, dibaca, atau gagal | Status terbaru per pesan dan kode galat bila gagal |
Banyak proyek berhenti di aliran pertama karena paling mudah dibuat. Masalahnya, tanpa aliran kedua dan ketiga, aplikasi tidak tahu apakah pesan sampai dan tidak bisa bereaksi pada balasan. Pengingat tagihan yang tidak terhubung ke balasan pelanggan, misalnya, tidak bisa menjeda pengingat saat pelanggan melapor sudah membayar. Alur penagihan lengkap dibahas di artikel penagihan otomatis via WhatsApp.
Webhook WhatsApp: cara aplikasi menerima pesan dan status
Webhook WhatsApp adalah alamat di aplikasi Anda yang dipanggil Meta setiap kali ada kejadian, misalnya pelanggan mengirim pesan atau status pesan berubah. Aplikasi tidak perlu terus-menerus bertanya ke WhatsApp, karena Meta yang mengirim kabar saat ada kejadian. Berikut cara kerjanya menurut dokumentasi resmi Meta per 31 Oktober 2026.
- 1
Verifikasi alamat webhook (permintaan GET)
Setiap kali Anda menyimpan atau mengubah Callback URL atau Verify token di App Dashboard, Meta mengirim permintaan GET berisi hub.mode, hub.challenge, dan hub.verify_token. Aplikasi mencocokkan hub.verify_token dengan teks rahasia yang Anda simpan, lalu membalas status 200 beserta nilai hub.challenge. Bila tidak, Meta menganggap alamat belum terverifikasi dan tidak mengirim webhook.
- 2
Menerima kejadian (permintaan POST)
Setiap ada kejadian pada kolom yang Anda langgani, Meta mengirim POST berisi JSON. Pesan masuk memuat antara lain nomor pengirim, ID pesan (berawalan wamid), waktu, jenis pesan, dan isinya. Pembaruan dapat dikirim berkelompok hingga 1.000 pembaruan dalam satu permintaan, jadi aplikasi harus siap memproses banyak entri sekaligus.
- 3
Memeriksa tanda tangan
Setiap POST membawa header X-Hub-Signature-256 yang berisi hash HMAC-SHA256 dari isi permintaan, dihitung dengan app secret Anda. Aplikasi menghitung hash yang sama dan membandingkannya. Bila cocok, payload sah; bila tidak, anggap tidak valid.
- 4
Membalas 200
Bila permintaan sah, aplikasi membalas status 200. Bila balasan bukan 200 atau pengiriman gagal, Meta mengulang segera, lalu beberapa kali lagi dengan jarak yang makin jarang hingga 7 hari. Permintaan yang tidak pernah dibalas 200 dibuang setelah 7 hari.
- 5
Memproses isi dan menyimpannya
Dokumentasi Meta menyatakan tidak ada API untuk mengambil riwayat webhook, jadi payload perlu disimpan sendiri. Aplikasi lalu mencocokkan pesan dengan pelanggan, memperbarui status, dan memicu tindakan yang sesuai.
| Ketentuan Meta | Dampak pada rancangan aplikasi |
|---|---|
| Pengiriman gagal diulang hingga 7 hari, dan pengulangan dapat menghasilkan notifikasi ganda | Setiap kejadian diberi penanda unik (misalnya ID pesan) dan diproses sekali saja; kejadian yang sama diabaikan |
| Pembaruan dikirim berkelompok hingga 1.000 per permintaan, dan pengelompokan tidak dijamin | Proses tiap entri secara terpisah; jangan mengandalkan satu permintaan berisi satu kejadian |
| Tidak ada API riwayat webhook | Simpan payload mentah beserta waktu terima sebelum diproses, agar kejadian bisa diperiksa atau diproses ulang |
| Payload dapat sampai 3 MB | Pastikan server dan proxy tidak membatasi ukuran permintaan lebih kecil dari itu |
| Tanda tangan HMAC-SHA256 tersedia pada setiap POST | Tolak permintaan yang tanda tangannya tidak cocok; hitung dari isi mentah sebelum dibaca sebagai JSON |
| mTLS didukung untuk webhook | Pilihan tambahan keamanan bila kebijakan perusahaan mensyaratkannya |
Tiga contoh integrasi: pesanan, pasien, dan tagihan
Tiga skenario berikut memakai pola yang sama (kejadian di aplikasi, template, balasan, tindakan di aplikasi) tetapi menekankan hal yang berbeda. Semuanya ilustrasi untuk menunjukkan alur, bukan hasil klien.
Pesanan: dari status gudang ke pelanggan
Pada perusahaan yang menjual atau mengirim barang, perubahan status pesanan di aplikasi menjadi pemicu pesan ke pelanggan. Balasan pelanggan, misalnya perubahan alamat atau pertanyaan resi, masuk kembali ke pesanan yang bersangkutan.
- Pemicu: status pesanan berubah menjadi 'dikirim' dan nomor resi terisi.
- Pesan: template status pesanan berisi nomor pesanan, resi, dan tautan pelacakan.
- Balasan: pelanggan menekan tombol 'Hubungi kami' atau menulis pertanyaan; aplikasi melampirkan percakapan ke pesanan dan memberi tahu staf layanan.
- Tindakan di aplikasi: status pesan tercatat, dan pesanan dengan pesan gagal terkirim muncul di daftar tugas staf.
Pasien: jadwal kunjungan dan konfirmasi
Pada klinik atau layanan home care, jadwal kunjungan di aplikasi menjadi pemicu pengingat. Balasan konfirmasi atau permintaan ubah jadwal langsung memperbarui jadwal, sehingga petugas pendaftaran tidak menelepon satu per satu. Karena menyangkut data kesehatan, perlindungan data (dibahas di bawah) perlu mendapat perhatian lebih.
- Pemicu: jadwal kunjungan besok tercatat di aplikasi.
- Pesan: template pengingat berisi nama, tanggal, jam, dan lokasi, tanpa diagnosis atau keluhan.
- Balasan: tombol 'Konfirmasi' atau 'Ubah jadwal'; konfirmasi mengubah status jadwal, sedangkan permintaan ubah jadwal menjadi tugas untuk petugas.
- Tindakan di aplikasi: daftar pasien hadir diperbarui, dan jadwal yang belum dikonfirmasi ditandai agar dihubungi lewat telepon.
Tagihan: invoice, pengingat, dan laporan sudah bayar
Pada perusahaan jasa, invoice yang terbit memicu pesan berisi invoice dan cara bayar. Pembayaran yang tercatat menghentikan pengingat, dan balasan pelanggan seperti 'sudah bayar' membuat tugas verifikasi untuk staf keuangan.
- Pemicu: invoice terbit, mendekati jatuh tempo, atau lewat jatuh tempo.
- Pesan: template tagihan dengan nomor invoice, nominal, dan jalur pembayaran.
- Balasan: 'Sudah bayar', 'Ada kendala', atau 'Minta tenggang'; masing-masing memicu tindakan berbeda.
- Tindakan di aplikasi: pembayaran tercatat menghentikan sisa pengingat, dan sengketa menjeda pengingat serta mengalihkan ke staf.
Mencocokkan nomor WhatsApp dengan data pelanggan di aplikasi
Pesan masuk dari WhatsApp hanya memuat nomor pengirim, bukan kode pelanggan atau nomor pesanan Anda. Aplikasi harus menebak entitas yang benar dari nomor itu, dan di sinilah banyak integrasi menjadi rapuh. Rancangan yang baik menyiapkan jawaban untuk kasus-kasus berikut sejak awal.
| Kasus | Masalah | Penanganan yang disarankan |
|---|---|---|
| Format nomor tidak seragam | Nomor tersimpan sebagai 0812..., +62812..., atau dengan spasi, sehingga tidak cocok dengan nomor dari webhook | Standarkan semua nomor ke satu format dengan kode negara 62 saat disimpan dan saat dicocokkan |
| Satu nomor dipakai beberapa pelanggan | Satu nomor kantor atau keluarga terhubung ke banyak data | Cocokkan ke entitas yang paling baru terkait, atau minta staf memilih bila ada lebih dari satu kandidat |
| Pelanggan punya lebih dari satu nomor | Balasan datang dari nomor yang tidak tercatat | Tandai sebagai pengirim tidak dikenal dan beri staf cara menautkannya ke pelanggan |
| Pengirim tidak dikenal | Orang baru menghubungi nomor bisnis | Buat percakapan tanpa pelanggan, lalu staf menautkan atau membuat data baru |
| Balasan menyangkut beberapa transaksi | Pelanggan punya tiga pesanan atau invoice terbuka dan hanya menulis 'sudah bayar' | Minta klarifikasi lewat pesan balasan atau tugas staf; jangan menebak |
Catat juga persetujuan (opt-in) per nomor: kapan, dari mana, dan untuk kategori pesan apa. Tanpa catatan itu, aplikasi tidak bisa menolak pengiriman ke nomor yang belum setuju. Aturan opt-in dibahas di artikel WhatsApp blast aman dan notifikasi WhatsApp otomatis.
Membaca status pesan: terkirim, sampai, dibaca, dan gagal
Setiap pesan yang dikirim aplikasi menghasilkan webhook status, dan status inilah yang membuat staf tahu siapa yang benar-benar menerima pesan. Ada beberapa nuansa yang perlu diperhatikan agar aplikasi tidak menarik kesimpulan yang salah.
| Status | Artinya | Catatan untuk aplikasi |
|---|---|---|
| Terkirim (sent) | Pesan sudah diterima server WhatsApp | Belum berarti sampai ke ponsel pelanggan |
| Sampai (delivered) | Pesan sudah sampai di perangkat penerima | Menurut dokumentasi Meta, bila pesan langsung dibaca saat penerima membuka chat, webhook 'delivered' bisa tidak dikirim karena sudah tersirat |
| Dibaca (read) | Penerima membuka pesan | Hanya muncul bila pesan telah sampai; fitur tanda baca penerima juga memengaruhinya |
| Gagal (failed) | Pesan tidak terkirim; webhook memuat kode galat | Simpan kode galat dan jadikan tugas bagi staf untuk menghubungi lewat saluran lain |
- Jangan menganggap status 'sampai' wajib ada sebelum 'dibaca'. Simpan status tertinggi yang pernah diterima per pesan.
- Jangan mengandalkan urutan kedatangan webhook. Karena ada pengulangan dan pengelompokan, status yang lebih lama bisa tiba setelah status yang lebih baru; bandingkan tingkat statusnya, bukan urutan masuknya.
- Pakai ID pesan dari respons pengiriman sebagai kunci untuk mencocokkan status yang datang belakangan dengan pesan yang Anda kirim.
- Tampilkan status di layar staf dengan bahasa sederhana, misalnya 'Belum sampai' atau 'Gagal terkirim', bukan kode teknis.
Memilih cara membangun: inbox penyedia, low-code, atau integrasi langsung
Tidak semua bisnis perlu integrasi langsung. Pilihan yang tepat bergantung pada seberapa banyak aturan bisnis yang menggerakkan pesan dan seberapa sensitif datanya. Tiga jalur berikut paling umum.
| Jalur | Cocok untuk | Kelebihan | Batas yang perlu disadari |
|---|---|---|---|
| Inbox dari penyedia resmi (BSP) | Tim layanan pelanggan yang butuh balas chat bersama, tanpa banyak aturan dari data internal | Cepat dipakai; ada antarmuka obrolan siap pakai | Data pesanan, pasien, atau tagihan tetap di aplikasi lain; kaitan ke transaksi terbatas |
| Alur low-code (misalnya n8n) | Notifikasi atau laporan sederhana dengan alur yang jelas dan beberapa sistem berbeda | Cepat dibangun dan mudah diubah; dibahas di artikel otomasi WhatsApp dengan n8n | Aturan bisnis rumit, banyak status, dan data sensitif makin sulit dirawat di alur visual |
| Integrasi langsung ke aplikasi custom | Perusahaan dengan banyak aturan bisnis, data sensitif, atau alur dua arah yang kompleks | Pesan, balasan, dan status menyatu dengan data dan hak akses aplikasi; kendali penuh atas alur | Biaya awal lebih besar dan butuh perawatan seiring perubahan aturan Meta dan alur bisnis |
Ketiganya sama-sama bertumpu pada akses resmi ke WhatsApp Business Platform. Cara mendapatkan akses itu dibahas di artikel cara mendapatkan WhatsApp API resmi, dan gambaran besarnya ada di panduan WhatsApp API untuk bisnis. Di Digipro, integrasi langsung adalah bagian dari layanan aplikasi custom, berdampingan dengan modul keuangan, laporan, dan alur kerja lain di aplikasi yang sama.
Keamanan dan privasi data dalam integrasi WhatsApp
Integrasi membuat aplikasi Anda menerima dan menyimpan percakapan pelanggan, sehingga keamanannya menjadi tanggung jawab Anda. Beberapa praktik dasar berikut berlaku untuk hampir semua integrasi; checklist keamanan aplikasi secara keseluruhan ada di Keamanan Aplikasi Internal Perusahaan.
- Periksa tanda tangan X-Hub-Signature-256 pada setiap permintaan webhook dan tolak yang tidak cocok. Alamat webhook yang terbuka tanpa pemeriksaan bisa dipanggil siapa saja.
- Simpan token akses, app secret, dan verify token hanya di sisi server, bukan di kode yang dikirim ke peramban atau aplikasi pengguna.
- Batasi isi pesan pada informasi yang perlu. Untuk jadwal kunjungan klinik, cukup nama, tanggal, jam, dan lokasi; hindari diagnosis, keluhan, atau hasil pemeriksaan.
- Atur hak akses di aplikasi: tidak semua staf perlu melihat semua percakapan, terutama yang menyangkut tagihan atau data kesehatan.
- Tentukan berapa lama payload mentah disimpan dan siapa yang boleh membukanya, lalu hapus atau anonimkan sesuai kebijakan retensi.
- Jangan meminta pelanggan mengirim nomor kartu, rekening, atau nomor identitas lengkap lewat chat; kebijakan WhatsApp Business Messaging Policy melarangnya.
Dari sisi hukum, UU Pelindungan Data Pribadi (UU No. 27 Tahun 2022) berlaku untuk data pelanggan dan pasien yang Anda proses. Undang-undang itu menggolongkan data dan informasi kesehatan sebagai data pribadi yang bersifat spesifik, sehingga integrasi untuk klinik dan layanan kesehatan sebaiknya ditinjau lebih ketat. Untuk pertanyaan kepatuhan yang spesifik, konsultasikan dengan penasihat hukum.
Berapa biaya integrasi WhatsApp dengan aplikasi internal?
Biaya integrasi terdiri dari tarif pesan Meta, kemungkinan biaya penyedia resmi, serta pembuatan dan perawatan integrasinya. Tarif rupiah sengaja tidak kami cantumkan karena berubah dan berbeda per kategori pesan; lihat daftar tarif resmi Meta atau minta rinciannya dari penyedia Anda. Sejak 1 Juli 2025 Meta menagih per pesan terkirim, bukan per percakapan.
| Komponen | Dibayar ke | Sifat biaya | Yang membuatnya naik |
|---|---|---|---|
| Tarif pesan | Meta, lewat penyedia resmi | Per pesan terkirim, sesuai kategori dan negara | Jumlah pesan dan jumlah tahap notifikasi per transaksi |
| Biaya penyedia resmi (BSP) | Penyedia WhatsApp Business Platform | Sesuai paket dan fitur | Fitur inbox, jumlah agen, dan dukungan tambahan |
| Pembuatan integrasi | Pembuat aplikasi | Biaya awal | Jumlah jenis pesan, aliran dua arah, dan aturan bisnis yang rumit |
| Server dan penyimpanan payload | Penyedia hosting | Berkala | Volume pesan dan lama penyimpanan |
| Perawatan | Pembuat aplikasi | Berkala | Perubahan template, aturan Meta, atau alur bisnis |
Pelajarannya sama dengan artikel notifikasi: biaya pesan mengikuti jumlah pesan, bukan jumlah pelanggan. Rincian lebih lengkap tentang tarif kategori dan jendela layanan ada di artikel chatbot WhatsApp untuk bisnis dan notifikasi WhatsApp otomatis. Estimasi tertulis untuk bisnis Anda kami berikan setelah konsultasi gratis.
Kesalahan umum dalam integrasi WhatsApp
- Hanya membangun pesan keluar tanpa menerima balasan dan status, sehingga aplikasi tidak tahu apa yang terjadi sesudah pesan dikirim.
- Tidak menyaring duplikat, padahal Meta mengulang pengiriman webhook yang gagal hingga 7 hari. Akibatnya status ganda, tugas ganda, atau pesan balasan ganda.
- Memproses semuanya sebelum membalas 200, sehingga balasan terlambat dan Meta mengulang pengiriman yang sebenarnya sudah diterima.
- Tidak menyimpan payload mentah. Bila ada kesalahan pemrosesan, kejadiannya tidak bisa diambil ulang karena tidak ada API riwayat webhook.
- Mencocokkan nomor dengan format yang tidak seragam, sehingga balasan pelanggan masuk ke 'pengirim tidak dikenal'.
- Menyimpan token dan app secret di tempat yang bisa diakses pengguna, atau tidak memeriksa tanda tangan webhook.
- Mengirim data sensitif, seperti keluhan pasien, di dalam isi pesan padahal pengingat jadwal sudah cukup.
- Tidak memantau status template dan kualitas nomor, sehingga pengiriman berhenti tanpa disadari.
Langkah membangun integrasi WhatsApp ke aplikasi internal
- 1
Pilih satu alur dengan dampak terbesar
Mulai dari satu alur, misalnya pengingat jadwal atau status pesanan, bukan semua sekaligus. Satu alur dua arah yang berjalan baik lebih berguna daripada lima alur yang setengah jadi.
- 2
Rapikan data dan standarkan nomor
Pastikan data pesanan, pasien, atau tagihan konsisten, dan nomor WhatsApp tersimpan dalam satu format dengan kode negara 62 beserta catatan opt-in.
- 3
Siapkan akses resmi dan template
Daftarkan nomor lewat jalur resmi, siapkan template per jenis pesan, dan ajukan lebih awal karena peninjauan template dapat memakan waktu hingga 24 jam.
- 4
Bangun endpoint webhook yang aman
Verifikasi alamat, periksa tanda tangan, simpan payload mentah, balas 200 dengan cepat, dan proses lewat antrean dengan penyaring duplikat.
- 5
Hubungkan pesan, balasan, dan status ke data aplikasi
Cocokkan nomor ke entitas, simpan status tertinggi per pesan, dan tentukan tindakan untuk tiap jenis balasan, termasuk saat aplikasi harus menyerahkan percakapan ke staf.
- 6
Uji, luncurkan bertahap, dan pantau
Uji dengan kejadian palsu dan nomor staf, luncurkan ke sebagian pelanggan lebih dulu, lalu pantau kegagalan pengiriman, status template, dan pesan dari pengirim tidak dikenal.
Langkah berikutnya
Jika Anda ingin tahu bagian mana dari aplikasi Anda yang paling layak dihubungkan ke WhatsApp lebih dulu, mulailah dengan konsultasi gratis. Ceritakan alur kerja saat ini: data apa yang menggerakkan pesan, siapa yang membalas pelanggan, dan di mana percakapan tersimpan sekarang. Di Digipro, integrasi WhatsApp dikerjakan sebagai bagian dari aplikasi custom, berdampingan dengan notifikasi, laporan otomatis, dan alur kerja lain. Versi pertama aplikasi umumnya selesai dalam 2–3 minggu, tergantung fitur, dan tahapannya dijelaskan di artikel tahapan pembuatan aplikasi custom.
Pertanyaan yang sering diajukan
Apa itu integrasi WhatsApp dengan aplikasi internal?
Integrasi WhatsApp dengan aplikasi internal adalah sambungan antara aplikasi perusahaan dan WhatsApp Business Platform lewat API, sehingga aplikasi bisa mengirim pesan dari data internal, menerima balasan pelanggan lewat webhook, dan mencatat status pengiriman. Dengan begitu staf tidak perlu memindahkan informasi secara manual antara aplikasi dan WhatsApp.
Apa itu webhook WhatsApp dan untuk apa dipakai?
Webhook WhatsApp adalah alamat di aplikasi Anda yang dipanggil Meta setiap kali ada kejadian, seperti pesan masuk dari pelanggan atau perubahan status pesan yang Anda kirim. Aplikasi memverifikasi alamat itu lewat permintaan GET, lalu menerima kejadian lewat POST yang bertanda tangan HMAC-SHA256 di header X-Hub-Signature-256 dan wajib dibalas dengan status 200.
Apa yang terjadi jika webhook saya gagal menerima kejadian?
Menurut dokumentasi Meta, pengiriman yang gagal diulang segera dan beberapa kali lagi dengan jarak yang makin jarang selama 7 hari, lalu dibuang bila tidak pernah dibalas 200. Karena pengulangan bisa menghasilkan notifikasi ganda, aplikasi perlu menyaring duplikat. Meta juga tidak menyediakan API untuk mengambil riwayat webhook, jadi simpan payload yang masuk.
Apakah balasan pelanggan bisa langsung memperbarui data di aplikasi?
Bisa. Balasan masuk lewat webhook, lalu aplikasi mencocokkan nomor pengirim dengan data pelanggan dan menjalankan tindakan yang sesuai, misalnya mengubah status jadwal saat pelanggan menekan tombol konfirmasi atau menjeda pengingat tagihan saat pelanggan melapor sudah membayar. Untuk balasan yang ambigu, lebih aman membuat tugas bagi staf daripada menebak.
Apakah integrasi WhatsApp aman untuk data pasien atau pelanggan?
Bisa aman bila dirancang benar: periksa tanda tangan webhook, simpan token hanya di server, batasi isi pesan pada informasi yang perlu, atur hak akses staf, dan tentukan kebijakan penyimpanan data. UU Pelindungan Data Pribadi menggolongkan data kesehatan sebagai data pribadi yang bersifat spesifik, jadi integrasi untuk klinik perlu ditinjau lebih ketat, sebaiknya dengan masukan penasihat hukum.
Kapan cukup memakai inbox penyedia, dan kapan perlu integrasi langsung?
Inbox dari penyedia resmi cukup bila kebutuhan utamanya tim layanan membalas chat bersama tanpa banyak aturan dari data internal. Alur low-code seperti n8n cocok untuk notifikasi atau laporan sederhana. Integrasi langsung ke aplikasi custom lebih masuk akal bila pesan digerakkan banyak aturan bisnis, melibatkan data sensitif, atau butuh alur dua arah yang menyatu dengan hak akses dan data aplikasi.
Bagikan artikel ini
Kirim ke rekan atau tim yang membutuhkannya.