Pada tahun 2023, kami melihat 100 perusahaan API teratas bersama dengan data internal Svix untuk memeriksa seberapa sering praktik terbaik webhook diterapkan di seluruh industri dan jenis dampak apa yang dimiliki praktik ini terhadap keandalan dan skalabilitas sistem webhook.
Tahun ini kami mengamati 100 perusahaan yang sama untuk melihat apakah dan seberapa besar adopsi webhook dan praktik terbaik implementasi telah meningkat. Kami juga mengamati lebih dari 100 perusahaan baru yang diklasifikasikan sebagai perusahaan rintisan oleh Forbes dalam 3 industri berbeda: Fintech, Developer Tools, dan AI untuk membandingkan tingkat adopsi webhook di berbagai industri serta berdasarkan tahap perusahaan.
Kami sangat senang melaporkan peningkatan adopsi webhook dan penerapan praktik terbaik secara menyeluruh. Kami ingin menganggap salah satu faktor utama yang berkontribusi terhadap tren ini adalah rilis spesifikasi Webook Standar yang menguraikan praktik terbaik untuk layanan webhook keluar dan permintaan berkelanjutan dari konsumen webhook untuk webhook yang lebih andal dan aman.
Tahun lalu, 83 dari 100 API teratas yang kami analisis menawarkan webhook. Ketika kami mengamati 100 API yang sama tahun ini, ada sedikit peningkatan hingga 85% adopsi webhook.
Satu pertanyaan yang ingin kami jawab dalam edisi State of Webhook ini adalah apakah perusahaan rintisan lebih cenderung menawarkan layanan webhook daripada penyedia API yang mapan. Di satu sisi, perusahaan rintisan cenderung mengadopsi teknologi baru lebih cepat, tetapi webhook cenderung menjadi fitur yang ditambahkan setelah peluncuran API.
Kami mengambil perusahaan rintisan dari daftar Forbes Fintech 50 dan AI 50 serta daftar 59 perusahaan rintisan DevTool teratas Failory dan menganalisisnya dengan cara yang sama seperti yang kami lakukan pada 100 perusahaan rintisan teratas API. Jelas, perusahaan rintisan agak tertinggal dalam adopsi webhook, terutama dalam AI yang cenderung menjadi bisnis yang lebih berfokus pada konsumen.
Percobaan ulang (mengirim ulang webhook jika percobaan gagal) adalah salah satu komponen mendasar dari sistem webhook yang andal, jadi kami gembira melihat peningkatan adopsi dari 67% menjadi 73%.
Kami juga melihat peningkatan dalam jumlah percobaan ulang yang ditawarkan dengan penurunan jumlah layanan yang hanya menawarkan 1 percobaan ulang dan peningkatan dalam jumlah layanan yang menawarkan 5+ percobaan ulang.
Mirip dengan bagaimana perusahaan rintisan tertinggal dalam adopsi webhook secara keseluruhan, mereka juga tertinggal dalam mengadopsi percobaan ulang. Terdapat tingkat adopsi yang jauh lebih rendah khususnya untuk perusahaan rintisan Devtool yang tidak terduga.
Fintech mewakili tingkat adopsi percobaan tertinggi yang masuk akal mengingat betapa pentingnya merespons peristiwa keuangan secara real-time dan tidak melewatkan/kehilangan data transaksi apa pun.
Meningkatkan waktu tunggu antar percobaan ulang secara progresif mengurangi risiko memperburuk masalah server, menangani masalah sementara dengan mengirimkan beberapa percobaan ulang pertama secara cepat, dan memberi pengguna banyak waktu untuk memperbaiki titik akhir yang gagal.
Penerapan jadwal mundur eksponensial untuk percobaan ulang juga meningkat dari 25/83 (30%) menjadi 31/83 (37%).
Narasi seputar adopsi kemunduran eksponensial bagi perusahaan rintisan sangat mirip dengan adopsi percobaan ulang secara keseluruhan. Perusahaan rintisan Fintech memimpin dengan perusahaan rintisan Devtool tertinggal jauh.
Berdasarkan %, peningkatan adopsi terbesar di antara semua praktik terbaik yang kami analisis adalah penerapan uji ulang manual (+71%). Tentu saja, ini adalah praktik terbaik yang paling rendah adopsinya dalam laporan tahun 2023 dan memiliki ruang perbaikan paling besar.
Kemampuan untuk mencoba ulang pesan secara manual mempercepat penyelesaian masalah. Lebih cepat untuk segera memicu percobaan ulang daripada menunggu percobaan ulang otomatis berikutnya.
Ini merupakan tren yang bagus untuk dilihat dan seharusnya membuat kehidupan konsumen webhook lebih mudah saat memecahkan masalah titik akhir yang gagal atau sekadar perlu mengirim peristiwa pengujian selama penyiapan dan pengujian awal.
Salah satu hasil yang paling mengejutkan adalah tingkat penerapan percobaan ulang manual oleh perusahaan rintisan AI. Dugaan terbaik kami mengenai alasan tingkat penerapan di antara perusahaan rintisan Fintech sangat rendah dibandingkan dengan praktik terbaik lainnya adalah karena biasanya terdapat banyak sekali pesan dalam sistem keuangan sehingga kemampuan untuk mencoba ulang satu transaksi jarang diperlukan.
Bila Anda memiliki banyak pesan, Anda biasanya ingin mencoba ulang semua pesan yang gagal secara massal atau bertahap. Produk AI cenderung memiliki volume pesan yang lebih rendah.
Peningkatan persentase besar lainnya terjadi pada jumlah layanan yang menawarkan log riwayat pesan. Ini adalah fitur hebat yang memungkinkan pengguna melakukan sendiri pemecahan masalah titik akhir yang gagal.
Hal ini tidak hanya menguntungkan konsumen yang tidak perlu menunggu respons dari dukungan untuk memperoleh jawaban mengapa mereka tidak menerima kejadian yang diharapkan, tetapi juga menguntungkan bagi penyedia webhook karena mereka menerima permintaan dukungan yang jauh lebih sedikit terkait kegagalan webhook.
Masalah juga dapat diselesaikan lebih cepat apabila pengembang dapat mendiagnosis sendiri masalah mereka sehingga fitur ini menguntungkan semua pihak.
Hasil aneh lainnya adalah bahwa adopsi pencatatan dan pemantauan pesan cukup merata di antara 100 penyedia API teratas vs. perusahaan rintisan, dan di seluruh industri.
Hal ini menunjukkan bahwa kemampuan untuk mendiagnosis sendiri dan memecahkan masalah kegagalan bukanlah hal yang unik bagi bidang atau tahap perusahaan tertentu, melainkan sesuatu yang diinginkan dan dimanfaatkan sepenuhnya oleh semua konsumen webhook.
Adopsi jenis peristiwa pada dasarnya sama (93% vs 94%) karena tingkat adopsi sangat tinggi sejak awal. Hal ini dikarenakan jenis peristiwa merupakan fitur inti dari setiap implementasi webhook karena Anda perlu memberi tahu pengguna peristiwa apa yang mereka terima.
Anehnya, adopsi jenis event sangat rendah untuk perusahaan rintisan AI. Dalam API 100, satu-satunya implementasi tanpa webhook adalah yang hanya memiliki satu event, jadi mungkin perusahaan AI hanya memiliki satu event untuk ditawarkan.
Sekali lagi, kami melihat peningkatan dalam penerapan praktik terbaik autentikasi pesan (HMACSHA256). Kami melihat peningkatan ini terjadi secara merata dari penurunan di semua metode autentikasi alternatif, tetapi terutama dari implementasi yang hanya meneruskan token Bearer.
Penerapan HMACSHA256 serupa di semua aspek. Hasil outlier berasal dari AI 50 di mana penyampaian rahasia langsung di header sangat populer. Menariknya, hal ini menjelaskan mengapa hanya sedikit dari AI 50 yang tidak menawarkan autentikasi webhook sama sekali.
Menyertakan stempel waktu sebagai bagian dari konten hash saat membuat tanda tangan HMAC membantu mencegah serangan replay. Tanpa stempel waktu sebagai bagian dari tanda tangan, pesan lama dapat diduplikasi dan dikirim lagi yang dapat menjadi masalah besar jika lembaga keuangan memproses transaksi yang sama dua kali.
Hal yang sama juga berlaku pada stempel waktu di tanda tangan. Penyedia API yang mapan mengungguli perusahaan rintisan dalam hal penerapan praktik terbaik.
Dokumentasi yang baik sangat penting untuk memberikan pengalaman pengembang yang luar biasa. Hal ini terutama berlaku untuk webhook yang memiliki beberapa "jebakan" yang dapat dialami pengembang saat mencoba menerapkan titik akhir mereka. Memiliki dokumentasi yang lengkap dapat membantu pengguna menghindari jebakan ini dan menghemat banyak waktu dan frustrasi.
Satu hal yang kami lihat dari layanan webhook terbaik adalah petunjuk pengujian. Ini juga mencakup kiat pemecahan masalah untuk masalah umum seperti kegagalan verifikasi tanda tangan.
Dalam hal dokumentasi, perusahaan rintisan setara dengan penyedia webhook yang lebih mapan. Hal ini juga logis karena dokumentasi merupakan hal mendasar bagi semua produk.
Elemen kunci yang kami lihat sebagai indikator dokumentasi webhook yang baik adalah contoh kode. Ini berlaku untuk sebagian besar dokumentasi API, tetapi khususnya untuk webhook. Sangat berguna untuk memiliki contoh titik akhir webhook yang berfungsi agar pengguna dapat memahami dengan tepat apa yang perlu dilakukan titik akhir mereka dan cara melakukannya.
Bersamaan dengan semua hal lain yang telah kita lihat dalam laporan sejauh ini, kita juga melihat lebih banyak contoh kode. Ini merupakan cerminan langsung dari peningkatan jumlah penyedia yang menawarkan autentikasi tanda tangan HMAC. Jika penyedia tidak menawarkan autentikasi sama sekali atau menawarkan metode yang lebih sederhana seperti autentikasi dasar atau header rahasia sederhana, contoh kode tidak terlalu diperlukan karena implementasinya jauh lebih sederhana.
Di sini, sebagian besar penyedia webhook, baik yang sudah mapan maupun yang baru memulai, menawarkan contoh kode kepada penggunanya. Pengecualiannya adalah perusahaan AI yang cenderung tidak menawarkan tanda tangan HMAC dan lebih condong ke header rahasia untuk autentikasi.
Mungkin pengguna AI tidak terlalu memperhatikan teknis atau keamanan seperti konsumen Fintech dan Devtool dan metode autentikasi yang lebih sederhana adalah yang terbaik untuk kasus penggunaan mereka. Tampaknya juga produk AI memiliki basis pengguna inti konsumen dan API serta webhook mereka merupakan penawaran sekunder untuk sebagian kecil pengguna mereka sehingga lebih sedikit upaya yang dilakukan untuk membuat layanan webhook mereka lebih aman/tangguh.
Kami dengan gembira melaporkan bahwa setelah memperbarui penelitian kami, kami melihat peningkatan menyeluruh dalam hal adopsi umum serta penerapan praktik terbaik.
Kami melihat jumlah pengadopsi baru konsisten di seluruh praktik terbaik yang memperlihatkan bahwa sebagian besar peningkatan adopsi berasal dari implementasi baru yang mengikuti sebagian besar praktik terbaik, bukan implementasi lama yang meningkatkan layanan webhook mereka.
Tahun ini kami menganalisis 150 perusahaan tambahan dari 3 daftar startup teratas yang berbeda di bidang Fintech, Devtools, dan AI untuk melihat apakah kami dapat menemukan tren antarindustri serta perbedaan antara startup dan penyedia API yang mapan.
Secara umum, kami melihat bahwa penyedia API yang mapan mengadopsi webhook pada tingkat yang lebih tinggi dan juga menerapkan lebih banyak praktik terbaik. Hal ini sangat logis karena penyedia yang mapan memiliki lebih banyak sumber daya untuk diinvestasikan dalam menawarkan solusi yang lebih baik dan perusahaan rintisan lebih cenderung meluncurkan versi MVP (minimum viable product) dari layanan webhook mereka.