Webhook Email Transaksional: Cara Memantau Status Kirim Tanpa Polling
API email Anda menjawab 202 Accepted. Kode itu hanya bilang satu hal: email sudah diterima antrean, belum tentu sampai ke inbox. Antara "terkirim" dan "terbaca" ada jarak yang bisa memakan biaya — OTP yang telat, invoice yang nyasar spam, konfirmasi booking yang tidak pernah dibaca pelanggan.
Cara tahu nasib email Anda bukan dengan nanya berulang-ulang ke API (polling), tapi dengan webhook: server email yang mendorong kabar ke Anda begitu status berubah.
Kenapa polling itu salah
Bayangkan Anda mengirim 50.000 email sebulan. Kalau setiap email Anda cek statusnya lewat GET /emails/:id sekali per menit selama 10 menit, itu 500.000 request — sebagian besar balasannya "masih diproses". Buang kuota, buang waktu, dan tetap telat tahu kabar buruk.
Webhook balik arah: Anda cukup sediakan satu endpoint, dan sistem email yang memanggilnya saat ada kejadian nyata — bounce, delivered, atau complaint. Tidak ada request yang sia-sia.
Status yang perlu Anda bedakan
Tidak semua "gagal" sama. Empat status ini mengubah cara Anda merespons:
| Status | Arti | Respons yang benar |
|---|---|---|
delivered |
Sampai ke inbox provider | Tidak perlu apa-apa |
bounced (hard) |
Alamat tidak ada / ditolak permanen | Hapus dari daftar, jangan kirim lagi |
bounced (soft) |
Inbox penuh / server sibuk | Boleh retry, tapi maksimal beberapa kali |
complaint |
Penerima tandai spam | Segera hentikan ke alamat itu |
Membedakan ini penting. Kalau Anda menyamakan soft bounce dengan hard bounce, Anda membuang pelanggan yang alamatnya sebenarnya valid. Sebaliknya, kalau Anda abaikan complaint, reputasi domain ikut hancur.
Tiga bisnis Indonesia yang bergantung pada status ini
Booking travel. Tiket pesawat atau hotel punya harga berubah cepat. Kalau konfirmasi booking tidak sampai, pelanggan menelepon support, atau lebih parah — cancel. Webhook delivered memberi kepastian; webhook bounced memicu fallback kirim ulang ke nomor lain atau notifikasi WA.
Invoice food delivery. Pesanan selesai, invoice harus keluar detik itu juga. Status bounced yang tidak terpantau berarti pelanggan tidak pernah lihat rincian biaya — padahal mereka sudah menunggu. Satu event webhook cukup untuk memicu alur "invoice gagal terkirim" ke tim.
OTP fintech. Verifikasi transaksi menunggu 6 digit di email. Kalau OTP bounce dan tidak ada yang tahu, transaksi menggantung, pelanggan panik. Monitoring webhook membuat OTP gagal langsung terlihat — dan bisa dialihkan ke SMS secara otomatis.
Ketiganya punya pola sama: email adalah bagian dari alur uang atau kepercayaan. Status kirim bukan sekadar log, tapi sinyal bisnis.
Contoh payload webhook
Endpoint Anda menerima POST dengan bentuk kira-kira begini:
{
"type": "email.bounced",
"email_id": "em_01J...",
"recipient": "[email protected]",
"reason": "hard_bounce",
"timestamp": "2026-08-27T02:15:00Z"
}
Dua hal yang wajib Anda lakukan di sisi penerima:
- Verifikasi tanda tangan. Webhook asli selalu datang dengan header
X-Signature(HMAC-SHA256) plus timestamp. Tolak request yang tanda tangannya tidak cocok atau umurnya lebih dari beberapa menit — mencegah orang lain menyamar sebagai server email. - Buat handler idempoten. Provider bisa mengirim ulang event yang sama. Simpan
email_id+type, dan abaikan duplikat.
Mulai dari mana
Jangan bangun infrastruktur webhook sendiri dari nol kalau yang Anda butuh cuma email transaksional yang andal. Cari penyedia yang sudah menangani antrean, retry, status per penerima, dan tanda tangan webhook secara bawaan — plus harga dalam Rupiah, bukan konversi kurs yang berubah-ubah.
Coba MailAnvil gratis di mailanvil.com — API email lokal untuk developer Indonesia, dengan webhook delivery status bawaan, harga IDR, dan pembayaran QRIS/GoPay.