Webhook Adalah: Pengertian, Cara Kerja & Bedanya dengan API

Aplikasi modern jarang bekerja sendirian. Toko online memakai payment gateway untuk menerima pembayaran, layanan pengiriman untuk melacak paket, dan aplikasi chat untuk melayani pelanggan. Pertukaran data di antara mereka umumnya berjalan lewat API, yaitu pintu yang disediakan sebuah aplikasi supaya aplikasi lain bisa meminta data. Masalahnya, API hanya menjawab ketika ditanya. Kalau toko Anda ingin tahu kapan pembeli selesai membayar, toko itu harus bertanya berulang-ulang sampai jawabannya berubah.

Webhook adalah cara membalik arah komunikasi itu. Alih-alih Anda yang terus bertanya, layanan lain yang mengabari server Anda begitu sesuatu terjadi. Artikel ini membahas apa itu webhook, cara kerjanya, bedanya dengan API, dan persiapan server penerimanya.

Apa Itu Webhook?

Webhook adalah permintaan HTTP otomatis yang dikirim sebuah layanan ke alamat URL milik Anda ketika suatu kejadian (event) terjadi. Kejadiannya bisa berupa pembayaran lunas, pesan WhatsApp masuk, kode baru di-push (diunggah) ke repositori, atau formulir yang baru diisi. Isi kiriman biasanya berupa data JSON yang menjelaskan apa yang terjadi.

Karena arahnya berlawanan dengan API biasa, webhook sering dijuluki reverse API atau HTTP callback (panggilan balik lewat HTTP). Istilahnya dipopulerkan Jeff Lindsay lewat tulisan blognya pada 3 Mei 2007. Ia meminjam istilah hook dari dunia pemrograman: titik kait tempat kode lain boleh "menumpang" ketika sebuah proses berjalan. Webhook membawa ide itu ke web dengan URL sebagai titik kaitnya.

Alat Getar di Food Court: Polling vs Webhook

Bayangkan Anda memesan makanan di food court. Ada dua cara mengetahui pesanan sudah siap. Cara pertama, Anda bolak-balik ke konter setiap beberapa menit dan bertanya. Cara kedua, kasir memberi Anda alat getar kecil yang akan berbunyi begitu makanan selesai dimasak, sehingga Anda bisa duduk tenang.

Cara pertama dalam dunia aplikasi disebut polling: aplikasi mengirim permintaan ke API secara berkala untuk mengecek perubahan. Cara kedua adalah webhook. Selisihnya besar: toko yang mengecek status pembayaran setiap satu menit mengirim 1.440 permintaan per hari. Kalau hari itu hanya ada tiga pembayaran, 1.437 permintaan, atau 99,8%, terbuang sia-sia. Pesanan yang lunas pun bisa baru diketahui hampir satu menit kemudian.

Analogi ini juga menyimpan kelemahan webhook. Alat getar hanya berguna kalau Anda berada dalam jangkauannya. Server yang sedang mati ibarat pengunjung yang keluar gedung: getarannya terjadi, tetapi tidak ada yang merasakan.

Cara Kerja Webhook Langkah demi Langkah

Cara kerja webhook terdiri dari empat tahap yang berulang setiap kali ada kejadian:

1. Pendaftaran URL: Anda mendaftarkan webhook URL (sering disebut endpoint) di dasbor layanan pengirim, misalnya https://tokoanda.com/webhook/pembayaran. Biasanya Anda juga memilih jenis kejadian yang ingin dikabarkan dan mendapat kunci rahasia untuk verifikasi.
2. Kejadian terjadi: Pembeli membayar, pelanggan mengirim pesan, atau developer mengunggah kode.
3. Pengiriman: Layanan pengirim membuat permintaan HTTP POST ke URL Anda. Badan permintaannya (payload) berisi data kejadian, sedangkan header-nya (bagian keterangan permintaan) membawa tanda tangan digital.
4. Balasan: Server Anda membaca kiriman lalu membalas dengan kode status 2xx, misalnya 200 OK. Kode itu tanda bagi pengirim bahwa kabarnya sudah diterima.

Isi payload berbeda di setiap layanan, tetapi polanya mirip. Contoh berikut menggambarkan kabar pesanan lunas:

{
  "id": "evt_8f2c41",
  "type": "order.paid",
  "created_at": "2026-10-10T09:15:22+07:00",
  "data": {
    "order_id": "INV-1042",
    "amount": 250000,
    "status": "paid"
  }
}

Kolom id adalah identitas unik kejadian, sedangkan type menyebut jenisnya. Kedua kolom ini nanti berperan penting saat server Anda harus menolak kiriman ganda.

Webhook vs API: Dua Arah dari Hubungan yang Sama

Perbedaan webhook dan API terletak pada siapa yang memulai percakapan. Pada API, termasuk REST API yang paling umum dipakai, aplikasi Anda bertanya lalu menunggu jawaban. Pada webhook, layanan lain yang datang membawa kabar tanpa ditanya. Tabel berikut merangkum perbedaannya:

Dalam praktik, keduanya saling melengkapi. Webhook memberi tahu bahwa sesuatu berubah, lalu aplikasi Anda memakai API untuk memastikan atau mengambil detailnya. Webhook juga berbeda dari WebSocket, yang menjaga satu koneksi tetap terbuka untuk percakapan terus-menerus seperti fitur chat. Webhook adalah permintaan lepas yang selesai begitu dibalas.

Webhook Discord dan Slack: Kenapa Arahnya Terbalik

Banyak orang pertama kali mengenal istilah ini dari webhook Discord. Di sini arahnya justru terbalik. Discord memberi Anda sebuah URL, lalu aplikasi Anda yang mengirim pesan ke URL itu supaya muncul di sebuah channel. Slack memakai pola yang sama. Bentuk ini disebut incoming webhook, yaitu webhook yang masuk ke Discord atau Slack, bukan keluar dari sana.

Mekanismenya tetap POST berisi JSON, hanya saja Anda kini pihak pengirim. Ingat dua hal berikut:

1. URL-nya adalah kata sandi: Discord menaruh token rahasia di dalam URL webhook. Siapa pun yang memegang URL itu bisa memposting ke channel Anda tanpa login. Slack bahkan aktif memindai dan mencabut URL webhook yang bocor ke repositori publik.
2. Ada batas isi pesan: Discord membatasi teks satu pesan webhook maksimal 2.000 karakter. Laporan yang lebih panjang harus dipecah atau dikirim sebagai lampiran.

Cara Membuat Webhook Discord

Membuat webhook Discord membutuhkan izin Manage Webhooks, yang otomatis dimiliki pemilik dan admin server. Langkahnya:

1. Buka Server Settings, pilih Integrations, lalu Webhooks.
2. Buat webhook baru, beri nama, dan pilih channel tujuannya.
3. Tekan Copy Webhook URL. Bentuknya https://discord.com/api/webhooks/<id>/<token>.

Untuk mencobanya, kirim pesan dari terminal dengan perintah berikut. Ganti ID dan TOKEN dengan bagian dari URL yang Anda salin:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"content":"Pesanan INV-1042 lunas"}' \
  "https://discord.com/api/webhooks/ID/TOKEN"

Pesan akan muncul di channel tujuan, sedangkan Discord membalas dengan kode 204 No Content tanpa isi.

Contoh Penggunaan Webhook

Lima contoh berikut paling sering ditemui pemilik website dan developer di Indonesia:

1. Notifikasi pembayaran: Payment gateway seperti Midtrans mengirim webhook saat status transaksi berubah, termasuk pembayaran QRIS dan virtual account. Kabar inilah yang seharusnya menandai pesanan lunas, bukan halaman "terima kasih" yang dilihat pembeli.
2. WhatsApp Business: WhatsApp Cloud API milik Meta mengirim webhook setiap ada pesan masuk atau status pesan berubah. Sebelum mulai mengirim, Meta memverifikasi URL Anda lewat permintaan GET berisi kode hub.challenge, dan server Anda harus mengembalikan kode itu apa adanya.
3. Deploy otomatis: GitHub bisa mengirim webhook setiap ada push, lalu server build menjalankan pengujian dan deploy tanpa disentuh manusia.
4. Bot Telegram: Bot Telegram menerima pesan lewat salah satu dari dua cara, polling dengan getUpdates atau webhook dengan setWebhook, tidak bisa keduanya sekaligus. Mode webhook mewajibkan HTTPS di port 443, 80, 88, atau 8443. Telegram juga bisa menyertakan header X-Telegram-Bot-Api-Secret-Token supaya server Anda tahu kiriman itu asli.
5. Otomasi tanpa kode: Di n8n, node Webhook menjadi titik awal alur kerja. Formulir yang dikirim, misalnya, langsung memicu penyimpanan ke spreadsheet dan pesan ke tim.

Kelebihan Webhook

Webhook populer karena empat keunggulan praktis:

1. Data datang hampir seketika: Pengirim biasanya mengabari dalam hitungan detik. Midtrans, misalnya, menargetkan notifikasi pelunasan terkirim paling lambat 20 detik.
2. Hemat sumber daya: Tidak ada permintaan yang terbuang hanya untuk memastikan "belum ada yang berubah".
3. Integrasi lebih sederhana: Aplikasi Anda tidak perlu penjadwal seperti cron job yang terus mengecek layanan lain.
4. Memakai HTTP biasa: Penerimanya cukup berupa halaman web yang menerima POST. Tidak ada protokol khusus yang perlu dipasang.

Sisi Lain Webhook yang Perlu Anda Pertimbangkan

Kesederhanaan webhook berpindah menjadi tanggung jawab penerima. Begitu URL Anda terdaftar, server Anda harus siap menghadapi beberapa kenyataan:

1. Kiriman bisa datang lebih dari sekali: Stripe, Midtrans, dan Meta sama-sama menyatakan satu kejadian bisa terkirim dua kali. Tanpa pengaman, satu pembayaran bisa tercatat ganda.
2. Urutannya tidak dijamin: Dokumentasi Midtrans mencontohkan notifikasi settlement (lunas) yang tiba lebih dulu daripada pending. Kalau server memproses keduanya secara berurutan, status akhir pesanan malah kembali menjadi "menunggu".
3. Bisa dipalsukan: URL webhook harus bisa diakses publik, sehingga siapa pun bisa mengirim POST ke sana. Tanpa verifikasi, penyerang cukup mengirim JSON palsu untuk "melunasi" pesanan.
4. Bisa terlewat: Saat server Anda mati, kiriman gagal. Ada penyedia yang mencoba lagi, tetapi ada juga yang menyerah.
5. Batas waktunya ketat: Balasan yang telat dianggap gagal meskipun datanya sebenarnya sudah diterima.

Seberapa besar risiko poin keempat dan kelima bergantung pada penyedianya. Berikut angka dari dokumentasi resmi masing-masing per Oktober 2026:

Artinya, server yang mati 30 menit akan kehilangan kiriman GitHub sampai Anda mengirim ulang secara manual. Kiriman Stripe pada kasus yang sama tetap datang sendiri.

Lima Kebiasaan Penerima Webhook yang Andal

Lima kebiasaan berikut mengatasi kelemahan tadi dan layak diterapkan sejak endpoint pertama Anda:

1. Balas dalam 3 detik, proses belakangan: Simpan kiriman ke antrean seperti Redis atau tabel database, lalu balas 200. Proses berat seperti mengirim email dikerjakan sesudahnya. Batas paling ketat di tabel tadi adalah 5 detik milik Shopify, dan respons 4–5 detik sudah ditandai berisiko.
2. Verifikasi tanda tangan: Kebanyakan penyedia menandatangani kiriman dengan HMAC (Hash-based Message Authentication Code), yaitu sidik jari pesan yang hanya bisa dibuat pemegang kunci rahasia. Hitung ulang sidik jari itu dari payload mentah, lalu bandingkan dengan header kiriman. Tolak juga kiriman yang cap waktunya (timestamp) lebih tua dari 5 menit supaya kiriman curian tidak bisa diputar ulang.
3. Catat ID kejadian: Simpan id setiap kiriman yang sudah diproses. Kalau ID yang sama datang lagi, balas 200 tanpa memprosesnya ulang.
4. Konfirmasi lewat API untuk hal penting: Untuk status pembayaran, ambil ulang status terbaru dari API penyedia. Cara ini sekaligus menyelesaikan masalah urutan yang tertukar.
5. Pakai HTTPS yang sah tanpa redirect: Stripe mewajibkan HTTPS dengan protokol enkripsi TLS versi 1.2 ke atas. Redirect 301 dan 302 dianggap gagal oleh Stripe dan tidak dicoba ulang oleh Midtrans. Kecualikan juga rute webhook dari proteksi CSRF (Cross-Site Request Forgery) bawaan framework, karena pengirim webhook tidak membawa token formulir.

Contoh berikut adalah penerima webhook minimal dalam PHP yang memverifikasi tanda tangan bergaya GitHub (header X-Hub-Signature-256):

<?php
$rahasia = getenv('WEBHOOK_SECRET');
$payload = file_get_contents('php://input');
$tandaTangan =
    $_SERVER['HTTP_X_HUB_SIGNATURE_256'] ?? '';

$seharusnya = 'sha256=' .
    hash_hmac('sha256', $payload, $rahasia);

if (!hash_equals($seharusnya, $tandaTangan)) {
    http_response_code(401);
    exit('tanda tangan tidak cocok');
}

file_put_contents(
    'antrean.jsonl',
    $payload . PHP_EOL,
    FILE_APPEND
);

http_response_code(200);
echo 'OK';

Fungsi hash_equals() membandingkan dua string dalam waktu yang sama panjang, sehingga penyerang tidak bisa menebak tanda tangan dari selisih waktu respons. Jangan ganti dengan operator ==. Dalam pengujian kami, kiriman bertanda tangan sah dibalas 200, sedangkan kiriman dengan tanda tangan karangan ditolak dengan 401.

Endpoint webhook juga harus menyala 24 jam dan cepat membalas. Untuk integrasi bervolume besar, menempatkannya di VPS Indonesia memberi Anda kendali penuh atas antrean, proses latar, dan sertifikat SSL-nya.

Cara Menguji Webhook Sebelum Dipakai Sungguhan

Pengirim webhook ada di internet, sedangkan kode Anda biasanya masih di komputer lokal. Tiga cara berikut menjembatani keduanya:

1. Webhook.site: Webhook tester daring ini bisa dipakai gratis. Ia memberi URL sementara dan menampilkan setiap kiriman lengkap dengan header dan isinya. Cocok untuk melihat bentuk payload sebelum menulis kode.
2. Terowongan ke localhost: Alat seperti ngrok memberi alamat publik yang meneruskan kiriman ke server di komputer Anda.
3. Alat bawaan penyedia: Stripe CLI punya perintah stripe listen untuk meneruskan event ke localhost. GitHub menyediakan riwayat pengiriman beserta tombol kirim ulang di pengaturan webhook.

Anda juga bisa membuat kiriman uji sendiri dari terminal. Perintah berikut menghitung tanda tangan HMAC lalu mengirim payload ke endpoint PHP di atas:

BODY='{"id":"evt_8f2c41","type":"order.paid"}'
SIG=$(printf '%s' "$BODY" \
  | openssl dgst -sha256 -hmac 'rahasia-anda' \
  | awk '{print $NF}')
curl -X POST \
  -H "Content-Type: application/json" \
  -H "X-Hub-Signature-256: sha256=$SIG" \
  -d "$BODY" https://tokoanda.com/webhook.php

Server akan membalas OK kalau kunci rahasia di kedua sisi sama.

Pertanyaan yang Sering Muncul

Apakah webhook butuh server sendiri?

Ya, penerima webhook butuh alamat publik yang selalu menyala. Hosting biasa yang menjalankan PHP cukup untuk volume kecil, sedangkan localhost tidak bisa dipakai di produksi.

Bagaimana cara membuat webhook?

Siapkan halaman di server Anda yang menerima permintaan POST, misalnya berkas PHP seperti contoh di atas. Daftarkan URL-nya di dasbor layanan pengirim, pilih jenis kejadian yang diinginkan, lalu uji dengan kiriman percobaan sebelum dipakai untuk transaksi sungguhan.

Apa itu webhook WhatsApp?

Webhook WhatsApp adalah URL di server Anda yang menerima kabar dari WhatsApp Business Platform, misalnya pesan masuk serta status pesan terkirim dan dibaca. Kiriman yang gagal dicoba ulang Meta selama 36 jam.

Apakah webhook aman?

Webhook aman selama penerimanya memverifikasi tanda tangan, memakai HTTPS, dan merahasiakan URL serta kuncinya. Tanpa verifikasi, endpoint webhook adalah pintu terbuka bagi data palsu.

Apakah webhook sama dengan callback?

Webhook adalah salah satu bentuk callback, yaitu "panggil saya kembali nanti", yang dijalankan lewat HTTP antara dua server.

Kesimpulan

Webhook membalik arah komunikasi antaraplikasi: layanan lain yang mengabari server Anda begitu sebuah kejadian terjadi, sehingga Anda tidak perlu bertanya terus-menerus lewat API. Hasilnya data hampir seketika dengan beban server yang jauh lebih ringan. Konsekuensinya, server penerima harus siap menghadapi kiriman ganda, tertukar urutan, palsu, atau terlewat.

Pakai webhook untuk kabar yang perlu ditindaklanjuti cepat, seperti pembayaran, pesan masuk, dan deploy. Tetap gunakan API untuk memastikan data yang menyangkut uang atau status penting.

Semoga artikel ini membantu.