--- title: "Apa Itu Webhook? Dasar Otomasi Antar Aplikasi" description: "Webhook membuat aplikasi saling memberi kabar secara otomatis. Pahami bedanya dengan polling API, isi payload, tanda tangan, keamanan, dan retry." url: "https://nivelva.com/insight/apa-itu-webhook" category: "AI \u0026 Otomasi" tags: ["webhook","api","otomasi","integrasi aplikasi","keamanan api"] author: "Theresia Candiawan" published: "2026-11-07T01:06:00+07:00" updated: "2026-11-07T01:06:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Apa Itu Webhook? Dasar Otomasi Antar Aplikasi > **Jawaban singkat:** Webhook adalah pesan HTTP yang dikirim otomatis oleh satu aplikasi ke alamat milikmu saat suatu kejadian terjadi, misalnya pembayaran berhasil. Berbeda dengan polling, kabar datang sendiri. Agar aman, verifikasi tanda tangan dan tangani kiriman ulang. Webhook adalah cara sebuah aplikasi memberi kabar ke aplikasi lain secara otomatis begitu sesuatu terjadi. Saat pelanggan membayar, payment gateway langsung mengirim pesan berisi detail transaksi ke alamat URL yang kamu daftarkan. Sistemmu menerima pesan itu dan bisa langsung bertindak: menandai pesanan lunas, mengirim struk, atau memberi tahu gudang. Webhook yang dipasang asal-asalan bisa membuat pesanan tercatat dua kali, notifikasi pembayaran hilang tanpa jejak, atau lebih buruk lagi, orang luar mengirim "kabar pembayaran" palsu ke sistemmu. Tiga risiko itu bisa dicegah dengan beberapa kebiasaan sederhana yang dibahas di bawah. ## Bagaimana webhook bekerja? Bayangkan dua cara menunggu paket. Cara pertama, kamu menelepon kurir setiap sepuluh menit untuk bertanya apakah paket sudah sampai. Cara kedua, kurir mengetuk pintu saat paket tiba. Cara pertama disebut **polling**, cara kedua adalah **webhook**. ### Alamat penerima (endpoint) Kamu menyiapkan sebuah URL yang siap menerima permintaan HTTP, biasanya dengan metode POST. URL ini didaftarkan di aplikasi pengirim, misalnya di dasbor payment gateway, layanan formulir, atau toko online. Alat otomasi seperti n8n menyediakan node khusus yang langsung memberi URL semacam ini, seperti dijelaskan di [apa itu n8n](https://nivelva.com/insight/apa-itu-n8n). ### Isi pesan (payload) Saat kejadian terjadi, pengirim mengirim data ke URL tersebut, umumnya dalam format JSON. Payload biasanya memuat jenis kejadian (misalnya pembayaran berhasil), ID objek, waktu, dan detail lain seperti nominal atau data formulir. Struktur persisnya ditentukan oleh dokumentasi masing-masing layanan. ### Balasan dari penerima Penerima wajib membalas dengan kode status HTTP sukses (kelompok 2xx) secepat mungkin. Balasan ini memberi tahu pengirim bahwa pesan sudah diterima. Kalau penerima lambat atau membalas dengan kode error, banyak layanan akan mencoba mengirim ulang. ## Webhook atau polling API: apa bedanya dalam praktik? Keduanya sah dan sering dipakai berdampingan. Tabel berikut merangkum perbedaannya. | Aspek | Webhook | Polling API | |:--|:--|:--| | Siapa yang memulai | Aplikasi pengirim | Sistem kamu | | Kecepatan kabar | Hampir seketika | Tergantung jarak pengecekan | | Beban permintaan | Hanya saat ada kejadian | Terus berjalan walau tidak ada data baru | | Kebutuhan teknis | URL publik yang bisa diakses dari internet | Cukup bisa memanggil API keluar | | Risiko utama | Kabar palsu, kiriman ganda, kiriman terlewat | Kuota API habis, data tertunda | | Cocok untuk | Pembayaran, formulir, pesan masuk, perubahan status | Sistem tanpa webhook, sinkronisasi berkala | Polling tetap berguna sebagai jaring pengaman. Banyak tim memakai webhook untuk kabar cepat, lalu menjalankan pengecekan terjadwal sekali sehari untuk mencocokkan data dan menangkap kiriman yang mungkin terlewat. ## Keamanan dan keandalan webhook URL webhook pada dasarnya pintu yang terbuka ke internet. Siapa pun yang tahu alamatnya bisa mengirim data ke sana. Karena itu, ada tiga hal yang perlu disiapkan. ### Verifikasi tanda tangan Banyak layanan menyertakan tanda tangan digital di header permintaan, umumnya hasil HMAC dari isi pesan dengan kunci rahasia yang hanya diketahui kamu dan pengirim. Penerima menghitung ulang tanda tangan itu dan menolak pesan yang tidak cocok. Cara persisnya, termasuk nama header dan algoritmanya, selalu ada di dokumentasi layanan pengirim. Bila layanan tidak menyediakan tanda tangan, alternatifnya adalah token rahasia di URL atau header, ditambah pengecekan ulang ke API pengirim untuk memastikan transaksi memang ada. > **Jangan langsung percaya status pembayaran:** > > Untuk kejadian bernilai uang, jangan menandai pesanan lunas hanya berdasarkan isi webhook yang belum diverifikasi. Cek tanda tangannya, atau ambil ulang status transaksi dari API resmi payment gateway sebelum mengirim barang. ### Kiriman ulang dan duplikasi Pengirim yang tidak menerima balasan sukses biasanya mencoba lagi beberapa kali. Akibatnya, pesan yang sama bisa datang lebih dari sekali. Sistemmu harus **idempoten**: simpan ID kejadian yang sudah diproses, lalu abaikan bila ID yang sama datang lagi. Tanpa ini, satu pembayaran bisa memicu dua pengiriman barang. ### Balas cepat, proses belakangan Kalau pemrosesan butuh waktu lama, misalnya memanggil beberapa sistem lain atau model AI, jangan biarkan pengirim menunggu. Terima pesan, simpan ke antrean, balas 2xx, lalu proses di langkah terpisah. Cara ini mengurangi kiriman ulang yang tidak perlu. ## Contoh webhook di bisnis sehari-hari **Payment gateway.** Pembayaran berhasil memicu alur: verifikasi, ubah status pesanan, kirim konfirmasi ke pelanggan, dan catat di pembukuan. Untuk pembayaran QRIS, prinsip pencatatannya dibahas di [QRIS untuk UMKM](https://nivelva.com/insight/qris-untuk-umkm). **Formulir website.** Setiap isian formulir kontak dikirim ke alur yang menyimpan data ke CRM, memberi tag sumber, dan memberi tahu tim penjualan di kanal chat. **Pendaftaran pelanggan baru.** Webhook dari sistem pendaftaran menjadi titik awal rangkaian pesan sambutan dan pengingat, seperti contoh di [otomasi onboarding pelanggan baru](https://nivelva.com/insight/otomasi-onboarding-pelanggan-baru). **Perubahan di repositori kode.** Layanan seperti GitHub bisa mengirim webhook saat ada push atau pull request, yang kemudian memicu proses build atau notifikasi tim. ## Kapan memilih webhook, kapan polling Pilih webhook bila layanan pengirim menyediakannya, kejadiannya penting untuk ditanggapi cepat, dan kamu bisa menyiapkan URL publik yang aman. Pembayaran, pesan pelanggan, dan pendaftaran hampir selalu lebih baik lewat webhook. Pilih polling bila sistem sumber tidak punya webhook, data cukup diperbarui berkala (misalnya laporan harian), atau server penerima berada di jaringan internal yang tidak bisa diakses dari luar. Polling juga lebih mudah diuji karena kamu yang mengendalikan jadwalnya. Untuk sistem penting, gabungkan keduanya: webhook untuk kecepatan, polling terjadwal untuk rekonsiliasi. ## Pertanyaan yang sering diajukan ### Apakah webhook sama dengan API? Webhook memakai mekanisme yang sama dengan API, yaitu permintaan HTTP, tetapi arahnya terbalik. Pada API biasa kamu yang meminta data, pada webhook pengirim yang mendorong data ke kamu. ### Apakah perlu server sendiri untuk menerima webhook? Perlu alamat yang bisa diakses dari internet. Bisa berupa server sendiri, layanan otomasi berbasis cloud, atau alat self-hosted seperti n8n di VPS. ### Bagaimana cara menguji webhook? Banyak layanan punya tombol kirim tes atau mode sandbox. Kamu juga bisa melihat isi kiriman di log alat otomasi untuk memastikan struktur datanya sesuai harapan. ### Apa yang terjadi kalau penerima sedang mati? Tergantung kebijakan pengirim. Sebagian mencoba ulang dalam jangka waktu tertentu, sebagian tidak. Karena itu pengecekan terjadwal sebagai cadangan tetap disarankan. --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/apa-itu-webhook Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com