Apa Itu Webhook? Dasar Otomasi Antar Aplikasi

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.

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.

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.

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.

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.

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.