🎉 Launch Offer: up to 97.2% OFF credits.See Plans
Webhook ialah panggilan balik HTTP yang menyampaikan data masa nyata kepada aplikasi anda apabila acara tertentu berlaku dalam sistem lain. Tidak seperti API tradisional di mana anda mengundur untuk kemas kini, webhook menolak data ke titik akhir anda dengan segera apabila dipicu, membolehkan pemberitahuan segera untuk acara e-mel seperti penghantaran, lantunan, pembukaan, dan klik.
Webhook mengubah cara anda berinteraksi dengan data e-mel dengan menghapuskan keperluan untuk mengundur tetap. Daripada berulang kali membuat pertanyaan API untuk menyemak acara baharu (yang membuang sumber dan memperkenalkan kelewatan), webhook menyampaikan maklumat pada saat ia tersedia. Keupayaan masa nyata ini adalah penting untuk operasi sensitif masa seperti mengeluarkan alamat melantun sebelum kempen seterusnya atau mencetuskan urutan susulan berdasarkan penglibatan penerima. Untuk pemasar e-mel dan pembangun, webhook membolehkan automasi canggih yang sebelum ini mustahil. Apabila seseorang mengklik pautan dalam e-mel anda, webhook boleh dengan segera mengemaskini CRM anda, mencetuskan pemberitahuan jualan, atau mendaftarkan kenalan dalam urutan pembimbing yang disasarkan. Respons segera terhadap tingkah laku pengguna ini secara dramatik meningkatkan kadar penglibatan dan penukaran. Webhook juga mengurangkan kos infrastruktur dan kerumitan. Pendekatan berasaskan undur memerlukan sumber berdedikasi untuk terus menyemak kemas kini, walaupun tidak ada apa-apa yang berubah. Dengan webhook, anda hanya memproses data apabila acara sebenarnya berlaku, menjadikan sistem anda lebih cekap dan boleh skala. Seni bina didorong acara ini kini merupakan amalan standard untuk infrastruktur e-mel moden.
Webhook beroperasi dengan mekanisme yang mudah tetapi kuat: apabila acara yang telah ditakrifkan terjadi, sistem sumber menghantar permintaan HTTP POST ke URL yang anda tentukan. URL ini, dipanggil titik akhir webhook, menerima beban JSON yang mengandungi maklumat terperinci tentang acara. Untuk sistem e-mel, ini bermakna aplikasi anda menerima pemberitahuan pada saat e-mel melantun, dibuka, atau mencetuskan sebarang acara lain yang dijejaki. Proses bermula apabila anda mendaftarkan URL titik akhir anda dengan penyedia perkhidmatan e-mel dan memilih acara mana yang anda ingin terima. Apabila pelanggan berlangganan membuka e-mel anda, contohnya, ESP mengesan tindakan ini dan segera membina beban yang mengandungi jenis acara, cap waktu, e-mel penerima, dan metadata relevan lain. Beban ini kemudian dihantar ke titik akhir anda melalui permintaan HTTP POST HTTPS. Pelayan anda mesti mengakui penerimaan dengan mengembalikan kod status HTTP 200. Jika webhook gagal untuk memberikan (kerana masa henti pelayan atau masalah rangkaian), kebanyakan penyedia melaksanakan logik cubaan semula dengan kemunduran eksponen. Ini memastikan anda akhirnya menerima semua data acara walaupun kegagalan sementara berlaku. Seluruh proses biasanya selesai dalam milisaat, memberikan anda keterlihatan hampir segera dalam prestasi e-mel anda.
API memerlukan anda untuk secara aktif meminta data (model tarik), manakala webhook secara automatik menghantar data kepada anda apabila acara berlaku (model tolak). Dengan API, anda mengundur pelayan secara berkala bertanya "sebarang acara baharu?" Dengan webhook, pelayan memberitahu anda dengan segera apabila sesuatu berlaku. Webhook lebih cekap untuk pemberitahuan masa nyata, manakala API lebih baik untuk penarikan data sesuai permintaan.
Laksanakan berbilang lapisan keselamatan: gunakan HTTPS secara eksklusif, sahkan tandatangan webhook menggunakan kunci rahsia yang disediakan oleh ESP anda, sahkan alamat IP sumber jika penyedia anda menerbitkannya, dan laksanakan had kadar untuk mencegah penyalahgunaan. Kebanyakan perkhidmatan e-mel menyertakan pengepala tandatangan (seperti X-Webhook-Signature) yang harus anda sahkan terhadap rahsia anda sebelum memproses sebarang beban.
Kebanyakan penyedia perkhidmatan e-mel melaksanakan logik cubaan semula automatik dengan kemunduran eksponen. Jika titik akhir anda mengembalikan ralat atau masa habis, penyedia akan cubakan penghantaran berkali-kali dalam beberapa jam atau hari. Walau bagaimanapun, selepas menghabiskan cubaan semula, acara mungkin hilang. Untuk mencegah kehilangan data, pastikan ketersediaan tinggi untuk titik akhir anda dan pertimbangkan menggunakan perkhidmatan webhook yang diurus atau baris gilir mesej sebagai penampan.
Titik akhir anda harus mengembalikan respons HTTP 200 dalam 5-10 saat untuk mencegah ralat masa habis. Amalan terbaik ialah mengakui penerimaan dengan segera, kemudian memproses beban secara tak segerak menggunakan baris gilir kerja latar belakang. Ini mencegah pemprosesan perlahan daripada menyebabkan kegagalan webhook dan membenarkan sistem anda mengendalikan volum peristiwa serentak yang tinggi tanpa halangan.
Mula gunakan EmailVerify hari ini. Sahkan e-mel dengan ketepatan 99.9%.
