--- title: "Cara Menghubungkan CRM ke Omnichannel Inbox dengan Webhook" description: "Hubungkan CRM ke omnichannel inbox dengan webhook: event yang disinkronkan, idempotensi, retry, pencocokan kontak, privasi data, dan arsitektur referensi." canonical: "https://omnichannels.ai/id/blog/connect-crm-omnichannel-inbox-webhooks/" language: "id" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "integration" primaryQuery: "connect crm to omnichannel inbox" keywords: ["integrasi CRM webhook", "idempotensi webhook", "pencocokan kontak WhatsApp CRM", "API omnichannel inbox", "verifikasi signature webhook", "arsitektur integrasi CRM dan pesan", "hubungkan CRM ke omnichannel inbox", "integrasi CRM WhatsApp"] published: "2026-10-10" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 8 answer: "Untuk menghubungkan CRM ke omnichannel inbox, berlangganan webhook inbox untuk event percakapan dan pesan. Terima event tersebut di endpoint kecil yang memverifikasi signature dan menyimpan setiap event satu kali berdasarkan event ID, lalu proses secara asinkron: cocokkan pengirim dengan kontak CRM melalui nomor telepon yang sudah dinormalisasi, email, atau ID media sosial, kemudian tulis aktivitas kembali ke CRM. Gunakan API inbox untuk arah sebaliknya, yaitu mengirim pesan atau memperbarui kepemilikan dari alur kerja CRM." takeaways: ["Webhook mendorong event dari inbox ke CRM secara hampir real time; API menarik data atau memicu aksi ke arah sebaliknya. Integrasi yang tangguh memakai keduanya.", "Pengiriman webhook umumnya bersifat at-least-once (minimal satu kali), sehingga penerima harus melakukan deduplikasi berdasarkan event ID dan siap menerima event yang datang tidak berurutan.", "Balas webhook dengan cepat dan jalankan pekerjaan CRM di antrean latar belakang, agar panggilan CRM yang lambat tidak memicu retry dan duplikasi.", "Cocokkan kontak berdasarkan pengenal yang sudah dinormalisasi, seperti nomor telepon format E.164 dan alamat email huruf kecil, dan jangan pernah menggabungkan data hanya berdasarkan nama.", "Kirim hanya data yang dibutuhkan CRM, jangan simpan isi pesan di CRM jika ringkasan sudah cukup, dan patuhi hukum privasi yang berlaku, seperti GDPR atau undang-undang perlindungan data di Uni Emirat Arab (UEA) dan Arab Saudi."] faq: - q: "Apa perbedaan webhook dan API untuk integrasi CRM?" a: "Webhook adalah permintaan HTTP yang dikirim inbox ke endpoint Anda ketika sesuatu terjadi, misalnya pesan baru masuk atau percakapan diselesaikan. API adalah layanan yang Anda panggil dari sistem Anda untuk membaca data atau menjalankan aksi, misalnya mengirim balasan atau memindahkan percakapan ke agen lain. Webhook menjaga CRM tetap mutakhir tanpa polling; API memungkinkan alur kerja CRM bertindak pada inbox." - q: "Apa arti idempotensi pada webhook?" a: "Idempotensi berarti memproses event yang sama dua kali memberi hasil yang sama seperti memprosesnya satu kali. Karena pengirim webhook akan mencoba ulang (retry) jika tidak menerima respons sukses tepat waktu, endpoint Anda bisa menerima event duplikat. Simpan ID unik setiap event, lewati ID yang sudah diproses, dan rancang penulisan ke CRM sebagai upsert agar event yang berulang tidak membuat aktivitas atau kontak kedua." - q: "Bagaimana cara mencocokkan nomor WhatsApp dengan kontak CRM?" a: "Normalisasi kedua sisi ke format internasional E.164, lengkap dengan kode negara, tanpa spasi dan tanpa angka nol di depan, lalu cari di CRM berdasarkan nilai tersebut. Jika tepat satu kontak cocok, hubungkan. Jika tidak ada yang cocok, buat lead atau kontak tanpa pasangan (unmatched). Jika ada beberapa yang cocok, jangan menebak; tandai percakapan agar agen yang memilih, lalu catat keputusannya untuk kasus berikutnya." - q: "Haruskah transkrip chat lengkap disimpan di CRM?" a: "Hanya jika Anda punya tujuan yang jelas dan dasar hukum. Banyak tim menyimpan di CRM tautan ke percakapan, ringkasan, hasil akhir, dan stempel waktu, sementara transkrip lengkap tetap berada di inbox dengan kontrol akses dan masa retensinya sendiri. Cara ini mengurangi duplikasi data pribadi dan mempermudah pemenuhan permintaan penghapusan data berdasarkan aturan seperti GDPR." - q: "Bagaimana cara mengamankan endpoint webhook?" a: "Sajikan endpoint hanya melalui HTTPS, verifikasi signature atau shared secret yang disertakan pengirim pada setiap permintaan, tolak permintaan dengan timestamp lama untuk membatasi replay, dan simpan secret di secrets manager, bukan di dalam kode. Batasi kemampuan endpoint: ia hanya boleh memasukkan event ke antrean, tidak membuka data CRM atau menerima perintah sembarang." sources: - title: "Webhooks — WhatsApp Cloud API, Meta for Developers" url: "https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks" - title: "The Idempotency-Key HTTP Header Field — IETF HTTPAPI Working Group draft" url: "https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/" - title: "RFC 2104: HMAC — Keyed-Hashing for Message Authentication" url: "https://www.rfc-editor.org/rfc/rfc2104" - title: "Regulation (EU) 2016/679 (GDPR) — EUR-Lex" url: "https://eur-lex.europa.eu/eli/reg/2016/679/oj" - title: "Data protection laws — The UAE Government portal (u.ae)" url: "https://u.ae/en/about-the-uae/digital-uae/data/data-protection-laws" --- # Cara Menghubungkan CRM ke Omnichannel Inbox dengan Webhook Canonical: https://omnichannels.ai/id/blog/connect-crm-omnichannel-inbox-webhooks/ Language: id Publisher: OmniChannels.ai by BroadNet Technologies Panduan ini ditujukan bagi CTO, arsitek solusi, dan administrator CRM yang ingin CRM dan omnichannel inbox mereka berbagi satu pandangan tentang pelanggan. Panduan ini menjelaskan event apa yang perlu disinkronkan, cara membangun penerima webhook yang tahan terhadap retry dan duplikasi, cara mencocokkan kontak di WhatsApp, Instagram, dan email, serta aturan privasi yang membentuk desain integrasi. ## Apa yang perlu dipertukarkan antara CRM dan omnichannel inbox? Inbox harus memberi tahu CRM siapa yang menghubungi Anda, lewat kanal apa, tentang apa, dan apa hasilnya. CRM harus memberi tahu inbox siapa pelanggan tersebut, siapa pemiliknya, dan konteks apa yang dibutuhkan agen. | Arah | Data | Penggunaan umum | |---|---|---| | Inbox ke CRM | Percakapan baru, kanal, pengenal kontak | Membuat atau memperbarui kontak, mencatat aktivitas | | Inbox ke CRM | Perubahan penugasan dan status, penyelesaian | Memperbarui timeline kasus atau deal, melaporkan waktu penanganan | | Inbox ke CRM | Status pengiriman pesan untuk template keluar | Melacak hasil kampanye atau notifikasi | | CRM ke inbox | Nama kontak, bahasa, pemilik akun, tier | Routing dan personalisasi | | CRM ke inbox | Pemicu untuk mengirim template yang sudah disetujui | Pembaruan pesanan, janji temu, atau kasus | | CRM ke inbox | Perubahan kepemilikan | Mengarahkan pelanggan yang kembali ke account manager mereka | Mulailah dari set data terkecil yang mendukung alur kerja nyata. Menyinkronkan seluruh isi pesan ke CRM jarang diperlukan dan menambah risiko privasi. ## Event webhook apa yang perlu Anda langganani? Berlangganan event siklus hidup percakapan, bukan hanya pesan. Nama event berbeda di setiap platform, jadi petakan ke kategori berikut: - **Percakapan dibuat (conversation created)** — pesan pertama dari pelanggan di kanal mana pun. - **Pesan diterima (message received)** — pesan masuk dari pelanggan, lengkap dengan kanal dan pengenal pengirim. - **Pesan dikirim (message sent)** — pesan keluar dari agen atau berupa template. - **Status pesan (message status)** — terkirim (sent), tersampaikan (delivered), dibaca (read), atau gagal (failed), sejauh kanal melaporkannya. - **Percakapan ditugaskan (conversation assigned)** — pemilik atau antrean berubah. - **Percakapan diselesaikan atau dibuka kembali (resolved or reopened)** — perubahan status. - **Kontak diperbarui (contact updated)** — pengenal atau atribut berubah di inbox. Untuk WhatsApp, webhook Meta sendiri mengirim pesan masuk dan pembaruan status pesan keluar ke platform; penyedia inbox Anda kemudian menyediakan event-nya sendiri ke sistem Anda. ## Bagaimana membangun penerima webhook yang andal? Terima dengan cepat, verifikasi, simpan sekali, proses belakangan. Sebagian besar masalah pengiriman muncul karena pekerjaan CRM dilakukan di dalam permintaan webhook. ### Desain penerima langkah demi langkah 1. **Sediakan satu endpoint HTTPS** per lingkungan, misalnya `/webhooks/inbox`. 2. **Verifikasi keaslian.** Periksa signature (umumnya HMAC dari raw body dengan shared secret, sebagaimana didefinisikan di RFC 2104) atau token yang didokumentasikan pengirim. Hitung pada raw bytes sebelum mem-parsing JSON. 3. **Periksa kebaruan.** Jika ada timestamp, tolak event di luar toleransi singkat untuk membatasi replay. 4. **Deduplikasi.** Masukkan event ID ke tabel dengan unique constraint. Jika insert gagal karena ID sudah ada, kembalikan respons sukses lalu berhenti. 5. **Masukkan ke antrean.** Taruh event di antrean dan segera kembalikan respons 2xx. 6. **Proses secara asinkron.** Worker membaca antrean, mencocokkan kontak, dan menulis ke CRM menggunakan upsert. 7. **Retry dengan backoff.** Jika CRM sedang tidak tersedia, lakukan retry dari antrean Anda dengan exponential backoff; jangan mengandalkan retry dari pengirim. 8. **Dead-letter.** Setelah beberapa kali gagal, pindahkan event ke dead-letter queue dan beri tahu seseorang. 9. **Rekonsiliasi.** Jalankan job berkala yang membandingkan percakapan inbox terbaru dengan data CRM dan mengisi celah dari API inbox. ### Mengapa idempotensi dan urutan itu penting Pengirim webhook biasanya melakukan retry ketika tidak menerima respons sukses tepat waktu, sehingga pengiriman bersifat at-least-once (minimal satu kali). Event yang sama bisa datang dua kali, dan event "resolved" bisa tiba sebelum "message received" yang terakhir. Tangani hal ini dengan: - Menggunakan event ID sebagai kunci deduplikasi. - Menggunakan upsert dengan kunci ID percakapan atau ID pesan di CRM. - Membandingkan timestamp atau nomor urut event dan mengabaikan status yang lebih lama. Ketika alur kerja CRM Anda memanggil API inbox untuk mengirim pesan, sertakan idempotency key jika API mendukungnya; draf IETF untuk header HTTP `Idempotency-Key` menjelaskan pola yang umum dipakai. ## Bagaimana mencocokkan kontak di berbagai kanal? Cocokkan berdasarkan pengenal yang sudah dinormalisasi, utamakan pencocokan deterministik, dan serahkan kasus ambigu kepada manusia. | Pengenal | Normalisasi | Tingkat keyakinan | Catatan | |---|---|---|---| | Nomor telepon WhatsApp atau SMS | E.164, misalnya +9715XXXXXXXX | Tinggi | Waspadai format lokal dengan angka nol di depan | | Alamat email | Huruf kecil, tanpa spasi | Tinggi | Alias bisa jadi orang yang sama; jangan berasumsi | | Akun Instagram | ID pengguna per platform | Tinggi dalam akun tersebut | Handle bisa berubah; simpan ID, bukan hanya handle | | Pengguna Telegram | ID pengguna platform | Tinggi dalam bot atau akun tersebut | Nomor telepon mungkin tidak dibagikan | | Nama | Tidak dipakai sendirian | Rendah | Jangan pernah menggabungkan data berdasarkan nama | Aturan keputusan: 1. Satu kecocokan persis: hubungkan. 2. Tidak ada kecocokan: buat lead atau "kontak tanpa pasangan" beserta kanal asalnya. 3. Beberapa kecocokan: tandai untuk agen, jangan gabungkan otomatis. 4. Pelanggan mengonfirmasi pengenal lain dalam percakapan: hubungkan dengan catatan buktinya. ## Bagaimana menangani privasi data dalam integrasi CRM? Pindahkan hanya apa yang dibutuhkan setiap sistem, dokumentasikan alasannya, dan pastikan penghapusan data berjalan di kedua sistem. - **Minimisasi data.** Simpan tautan percakapan, hasil akhir, dan ringkasan di CRM; simpan transkrip lengkap di inbox kecuali ada tujuan yang jelas. - **Dasar hukum dan persetujuan.** Catat persetujuan (opt-in) pemasaran per kanal; percakapan dukungan bukan persetujuan untuk template pemasaran. - **Retensi.** Selaraskan masa retensi di inbox, CRM, antrean, dan log; log payload webhook sering terlupakan. - **Kontrol akses.** Batasi siapa yang dapat melihat isi pesan dan lampiran di CRM. - **Permintaan penghapusan dan akses data.** Pastikan permintaan di satu sistem diteruskan ke sistem lainnya. - **Transfer lintas negara.** Periksa di mana setiap sistem menyimpan data. GDPR berlaku untuk data pribadi orang-orang di Uni Eropa, dan Uni Emirat Arab (UEA) serta Arab Saudi memiliki undang-undang perlindungan data pribadi masing-masing; konfirmasikan kewajiban terbaru dengan regulator terkait dan tim hukum Anda. ## Seperti apa arsitektur referensinya? Dalam bentuk teks, alurnya: kanal ke inbox, inbox ke penerima, penerima ke antrean, antrean ke worker, worker ke CRM, dan alur kerja CRM kembali ke API inbox. | Komponen | Tanggung jawab | Keputusan desain utama | |---|---|---| | Kanal (WhatsApp, Instagram, email, Telegram) | Mengirim pesan pelanggan ke inbox | Diatur oleh aturan masing-masing platform | | Omnichannel inbox | Percakapan, penugasan, agen, event | Mengirim webhook; menyediakan API | | Penerima webhook | Verifikasi, deduplikasi, masukkan ke antrean | Stateless, respons 2xx cepat | | Event store dan antrean | Buffer yang tahan lama, replay | Event ID unik, dead-letter queue | | Sync worker | Pencocokan kontak, upsert CRM | Penulisan idempoten, backoff | | CRM | Kontak, deal, kasus, alur kerja | Memanggil API inbox dengan idempotency key | | Job rekonsiliasi | Mendeteksi dan memperbaiki celah | Berjalan terjadwal | | Monitoring | Lag, kegagalan, dead letter | Peringatan ke penanggung jawab | ## Contoh kasus: grup klinik di Jeddah "Wahat Clinics", grup layanan kesehatan fiktif di Arab Saudi, memakai CRM untuk janji temu pasien dan inbox untuk WhatsApp dan email. - Seorang pasien mengirim pesan di WhatsApp. Inbox mengirim event percakapan dibuat; penerima memverifikasi, menyimpan, dan memasukkannya ke antrean. - Worker menormalisasi nomor ke E.164, menemukan satu data pasien, dan mencatat aktivitas berisi tautan ke percakapan, bukan teks pesannya. - CRM menunjukkan bahasa pilihan pasien adalah bahasa Arab dan mendorongnya ke inbox, yang kemudian mengarahkan ke antrean berbahasa Arab. - Saat janji temu dipesan di CRM, sebuah alur kerja memanggil API inbox untuk mengirim konfirmasi berupa template utilitas (utility) yang sudah disetujui, dengan ID janji temu sebagai idempotency key sehingga retry tidak mengirim dua konfirmasi. - Event "message delivered" dari inbox memperbarui data janji temu. ## Apa saja kesalahan yang umum terjadi? - **Menulis ke CRM di dalam permintaan webhook**, yang menyebabkan timeout, retry, dan duplikasi. - **Tanpa deduplikasi**, sehingga muncul aktivitas dan kontak ganda. - **Mencocokkan nomor telepon yang belum dinormalisasi**, sehingga format +971 dan format berawalan 0 tidak pernah bertemu. - **Menggabungkan otomatis berdasarkan nama atau kecocokan parsial.** - **Menyalin seluruh isi pesan ke CRM** tanpa tujuan atau aturan retensi. - **Tanpa rekonsiliasi**, sehingga satu event yang terlewat menjadi selisih data permanen. - **Secret di dalam kode sumber**, tanpa rencana rotasi. ## Bagaimana OmniChannels.ai membantu OmniChannels.ai, didukung oleh BroadNet Technologies, menyatukan percakapan WhatsApp, Instagram, Messenger, Telegram, dan Email dalam satu [Omni Inbox](/platform/unified-inbox/) dengan penugasan agen dan tagging, ditambah onboarding (aktivasi akun) WhatsApp melalui Meta Embedded Signup dan template yang disetujui dengan variabel, media, dan tombol. Untuk integrasi CRM, [REST API](/developers/) didokumentasikan secara publik dengan spesifikasi OpenAPI 3.1, dan [webhook](/developers/webhooks/) melaporkan status pengiriman (SENT, DELIVERED, READ, FAILED, dan lainnya) dalam satu format yang seragam. Laporan pengiriman (DLR) dengan filter dan ekspor CSV mendukung proses rekonsiliasi. Mulai dari halaman [developers](/developers/).