Langsung ke konten utama
Webhook alert mengirim alert tim Anda ke endpoint HTTPS yang Anda miliki. Gunakan untuk meneruskan alert ke alat on-call, antrean tiket, atau dasbor operasional Anda sendiri. Webhook alert terpisah dari webhook verifikasi. Webhook verifikasi mengirim hasil sesi, entitas, dan transaksi ke aplikasi Anda. Webhook alert memberi tahu tim Anda bahwa ada sesuatu yang perlu perhatian: verifikasi yang menunggu peninjauan, pembayaran yang gagal, atau insiden layanan. Webhook ini memiliki payload, rahasia penandatanganan, tanda tangan, dan jadwal coba lagi sendiri.

Siapkan tujuan

Anda mengonfigurasi webhook alert di Business Console, bukan melalui API. Anggota yang dapat mengelola pengaturan organisasi dapat menambahkan, mengubah, dan menguji tujuan.
1

Tambahkan tujuan

Di Pengaturan organisasi > Notifikasi tim, tambahkan tujuan Webhook alert dengan URL endpoint Anda. URL harus menggunakan https:// dan mengarah ke alamat publik.
2

Simpan rahasia penandatanganan

Didit hanya menampilkan rahasia penandatanganan lengkap, yang diawali whsec_, sekali saja. Simpan sekarang: setelah itu konsol hanya menampilkan empat karakter terakhirnya.
3

Arahkan alert ke tujuan

Menambahkan tujuan tidak langsung mengirim apa pun ke tujuan tersebut. Tambahkan tujuan ke aturan perutean untuk alert yang ingin Anda terima.
4

Kirim tes

Klik Kirim tes untuk mengirim alert alert.test, lalu pastikan endpoint Anda menerimanya.
Sebuah organisasi dapat memiliki hingga 25 tujuan di Notifikasi tim. Hanya aktivitas produksi yang sampai ke tujuan. Alert tentang verifikasi sandbox, verifikasi bisnis, transaksi, dan temuan AML tidak pernah dikirim ke tujuan tersebut.

Jenis alert

Payload

Setiap alert berupa POST dengan body JSON. Didit mengirim body sebagai JSON ringkas dengan kunci yang diurutkan. Contoh ini diformat agar mudah dibaca:
data selalu berisi:
  • event: kunci event, misalnya session_in_review.
  • label dan value: hal yang dibahas alert, misalnya Session dan #1042.
Beberapa jenis alert menambahkan kunci ke data:
  • alert.billing.autorefill_failed menambahkan paused, boolean yang bernilai true jika isi saldo otomatis kini dijeda hingga Anda memperbarui kartu.
  • alert.service.degraded dan alert.service.recovered menambahkan service, status, incident_id, service_name, state, affected, country_name, started_at, resolved_at, duration_minutes, title, dan body. status bernilai degraded atau down pada alert.service.degraded, dan recovered pada alert.service.recovered. service menggunakan kunci layanan dari GET /v3/status/, dan incident_id cocok dengan id insiden di sana.
Alert tidak pernah menyertakan data pribadi pengguna akhir atau data dokumen. Alert mengidentifikasi sesi, transaksi, atau item lain dengan nomornya dan menautkannya ke konsol. Abaikan nilai webhook_type dan kunci data yang tidak Anda kenali, agar nilai atau kunci baru tidak merusak endpoint Anda.

Header permintaan

Verifikasi tanda tangan

X-Signature-V2 adalah HMAC-SHA256 dari string <X-Timestamp>.<raw body> yang dienkode dalam heksadesimal, dengan kunci berupa rahasia penandatanganan tujuan webhook Anda.
  • Gunakan rahasia lengkap persis seperti yang ditampilkan Didit, termasuk awalan whsec_.
  • Tandatangani byte mentah dari permintaan sebagaimana Anda menerimanya. Mem-parsing JSON lalu men-serialisasi ulang dapat mengubah byte dan membuat pemeriksaan gagal.
  • Bandingkan tanda tangan dalam waktu konstan.
  • Tolak permintaan yang X-Timestamp-nya berselisih lebih dari 5 menit dari jam Anda. Didit menandatangani setiap percobaan, termasuk setiap coba lagi, dengan timestamp baru, sehingga jendela ini tidak pernah menolak coba lagi yang sah.
  • Balas pemeriksaan yang gagal dengan 400. Respons 401, 403, 404 atau 410 menandai tujuan untuk dihubungkan ulang (lihat Coba lagi).
Alert webhook tidak ditandatangani seperti webhook verifikasi. Header-nya juga bernama X-Signature-V2, tetapi string yang ditandatangani berbeda, dan alert webhook tidak mengirim X-Signature maupun X-Signature-Simple. Jangan menggunakan ulang verifikator webhook verifikasi Anda.

Node.js (Express)

Python (Flask)

Rotasi rahasia penandatanganan

Anda merotasi rahasia pada tujuan di Notifikasi tim. Didit menampilkan rahasia baru sekali saja dan menandatangani setiap percobaan berikutnya dengan rahasia tersebut, termasuk coba lagi untuk alert yang dibuat sebelum rotasi. Rahasia lama langsung berhenti berfungsi. Tidak ada periode tumpang tindih, dan tidak ada header yang memuat tanda tangan yang dibuat dengan rahasia sebelumnya. Terapkan rahasia baru ke endpoint Anda segera setelah Anda merotasinya.

Coba lagi

Didit menganggap respons 2xx apa pun sebagai terkirim. Setiap percobaan menunggu hingga 5 detik untuk respons Anda dan tidak mengikuti pengalihan. Didit mencoba lagi mengirim alert setelah batas waktu, kegagalan koneksi, respons 5xx, atau respons 408, 425 atau 429. Didit mencoba hingga 5 kali, selama sekitar 24 jam: Respons lainnya bersifat final, termasuk 3xx dan 4xx lainnya. Tes yang dikirim dengan Kirim tes mendapat satu percobaan dan tidak pernah dicoba ulang. Respons 401, 403, 404 atau 410 juga menandai tujuan untuk dihubungkan ulang: konsol menampilkannya dengan status Hubungkan ulang. Hal yang sama berlaku untuk URL yang mengarah ke alamat privat atau alamat lain yang diblokir saat Didit mengirim. Didit terus mengirim alert baru ke tujuan tersebut, dan tujuan kembali aktif setelah pengiriman berhasil berikutnya atau saat Anda memperbarui URL-nya. Notifikasi terbaru di Notifikasi tim mencantumkan setiap pengiriman beserta hasilnya, dan Anda dapat mencoba ulang pengiriman yang gagal dari sana.

Terkait

  • Webhook verifikasi: hasil sesi, entitas dan transaksi untuk aplikasi Anda.
  • Status layanan: umpan publik di balik alert.service.degraded dan alert.service.recovered.
  • Peninjauan manual: apa yang harus dilakukan dengan verifikasi dalam peninjauan.
Terakhir diubah pada 7 November 2026