בשנת 2023, בדקנו את 100 חברות ה-API המובילות יחד עם נתוני Svix פנימיים כדי לבחון באיזו תדירות מיושמים שיטות עבודה מומלצות ל-webhook בכל התעשייה ואיזו סוג של השפעה יש לשיטות העבודה הללו על המהימנות והמדרגיות של מערכות webhook. השנה בדקנו את אותן 100 חברות כדי לראות אם ועד כמה גדל האימוץ של webhooks ושיטות עבודה מומלצות ליישום. בדקנו גם למעלה מ-100 חברות חדשות שסווגו כסטארט-אפים על ידי פורבס ב-3 תעשיות שונות: פינטק, כלים למפתחים ובינה מלאכותית כדי להשוות את שיעורי אימוץ ה-webhook בין התעשיות, כמו גם לפי שלב החברה. אנו שמחים מאוד לדווח על עלייה בכל רחבי הלוח באימוץ webhook והטמעה של שיטות עבודה מומלצות. ברצוננו לחשוב שאחד הגורמים התורמים העיקריים למגמה הוא שחרורו של מפרט ה-Webhook הסטנדרטי שמתאר שיטות עבודה מומלצות לשירות חיבור אינטרנט יוצא ודרישה מתמשכת מצרכני ה-webhook ל-webhook אמינים ומאובטחים יותר. אימוץ Webhook בשנה שעברה, 83 מתוך 100 ממשקי ה-API המובילים שניתחנו הציעו webhooks. כאשר הסתכלנו על אותם 100 ממשקי API השנה, הייתה עלייה קטנה ל-85% אימוץ webhook. שאלה אחת שרצינו לענות עליה במהדורה זו של State of Webhooks, הייתה האם יש סיכוי גבוה יותר או פחות לסטארט-אפים להציע שירות webhook מאשר ספקי API מבוססים. מצד אחד, סטארט-אפים נוטים לאמץ טכנולוגיות חדשות מהר יותר, אבל webhooks נוטים להיות תכונה שמקבלת תוספת לאחר השקת API. לקחנו את הסטארט-אפים מרשימות Forbes Fintech 50 ו-AI 50, כמו גם מ-59 הסטארט-אפים המובילים של Failory וניתחנו אותם באותו אופן שבו עשינו את ה-API המובילים 100. ברור שסטארט-אפים מפגרים מעט באימוץ webhook, במיוחד ב-AI אשר נוטה להיות עסקים ממוקדים יותר בצרכנים. מנסה שוב ניסיונות חוזרים (שליחה מחדש של webhook אם ניסיון נכשל) הם אחד המרכיבים הבסיסיים של מערכת webhook אמינה ולכן אנו שמחים לראות עלייה באימוץ מ-67% ל-73%. ראינו גם עליות במספר הניסיונות החוזרים המוצעים עם ירידה במספר השירותים המציעים רק ניסיון חוזר אחד ועלייה במספר השירותים המציעים 5+ ניסיונות חוזרים. בדומה לאופן שבו סטארט-אפים פיגרו באימוץ כללי של חיבורי אינטרנט, הם גם מפגרים באימוץ ניסיונות חוזרים. יש שיעור אימוץ נמוך משמעותית במיוחד עבור סטארט-אפים של Devtool, וזה היה בלתי צפוי. Fintech מייצג את שיעור האימוץ הגבוה ביותר של ניסיונות חוזרים, וזה הגיוני בהתחשב במידת החשיבות של תגובה לאירועים פיננסיים בזמן אמת ולא לפספס/לאבד שום נתוני עסקה. נסיונות חוזרים: גיבוי אקספוננציאלי הגדלה הדרגתית של זמן ההמתנה בין ניסיונות חוזרים מפחיתה את הסיכון להחמרת בעיות שרת כלשהן, מטפלת בבעיות חולפות על ידי שליחת כמה ניסיונות חוזרים ראשונים במהירות, ונותנת למשתמשים מספיק זמן לתקן נקודות קצה כושלות. גם אימוץ לוח הזמנים של גיבוי אקספוננציאלי לניסיונות חוזרים עלה מ-25/83 (30%) ל-31/83 (37%). הנרטיב סביב אימוץ גיבוי אקספוננציאלי עבור סטארט-אפים דומה מאוד לאימוץ של ניסיונות חוזרים בסך הכל. סטארט-אפים של Fintech מובילים את הדרך עם סטארט-אפים של Devtool בפיגור משמעותי. ניסיונות חוזרים ידניים על בסיס %, העלייה הגדולה ביותר באימוץ מבין כל השיטות הטובות ביותר שניתחנו הייתה הטמעת ניסיונות חוזרים ידניים (+71%). כמובן שזה היה השיטות הטובות ביותר שאומצו בדוח 2023 והיה לו הכי הרבה מקום לשיפור. היכולת לנסות שוב הודעות באופן ידני מאיץ את פתרון הבעיות. מהיר יותר להפעיל ניסיון חוזר באופן מיידי במקום לחכות לניסיון החוזר האוטומטי הבא. זוהי מגמה נחמדה לראות ואמורה להפוך את חייהם של צרכני webhook לקלים הרבה יותר בעת פתרון בעיות בנקודות קצה כושלות או פשוט צורך לשלוח אירועי בדיקה במהלך ההגדרה והבדיקה הראשונית. אחת התוצאות המפתיעות ביותר הייתה הקצב שבו סטארט-אפים בינה מלאכותית מאמצים ניסיונות חוזרים ידניים. הניחוש הטוב ביותר שלנו לגבי הסיבה לכך ששיעור האימוץ בקרב סטארט-אפים של Fintech הוא כל כך נמוך כאן בהשוואה לשיטות העבודה המומלצות האחרות הוא שבדרך כלל יש נפח גדול של הודעות במערכות פיננסיות, כך שהיכולת לנסות שוב עסקה בודדת היא לעתים נדירות הכרחית. כאשר יש לך נפח גבוה של הודעות, בדרך כלל תרצה לנסות שוב את כל ההודעות שנכשלו בכמות גדולה או בקבוצות. מוצרי AI נוטים להיות בעלי נפח הודעות נמוך יותר. רישום וניטור עלייה גדולה נוספת באחוזים הייתה במספר השירותים המציעים יומני היסטוריית הודעות. זוהי תכונה נהדרת המאפשרת למשתמשים לתת שירות עצמי בפתרון בעיות של נקודות קצה כושלות. זה לא רק מועיל לצרכן שלא צריך להמתין לתגובה מהתמיכה כדי לקבל תשובות למה הם לא מקבלים את האירועים הצפויים שלהם, אלא שזה גם מועיל לספק ה-webhook שכן הוא מקבל פחות בקשות תמיכה סביב webhook כשלים. בעיות גם נפתרות מהר יותר כאשר מפתחים יכולים לאבחן את הבעיות שלהם בעצמם, כך שתכונה זו היא מנצחת לכולם. סוגי אירועים תוצאה מוזרה נוספת היא שהאימוץ של רישום וניטור של הודעות הוא די שווה בכל הטווח בין 100 ספקי ה-API המובילים לעומת סטארט-אפים, ובתעשיות. זה מצביע על כך שהיכולת לאבחן עצמי ולפתור תקלות אינה ייחודית לאף תחום או שלב מסוים בחברה והיא פשוט משהו שכל צרכני ה-webhook רוצים ומרוויחים ממנו מאוד. אימוץ סוג האירוע היה זהה במהותו (93% לעומת 94%) מכיוון ששיעור האימוץ היה כה גבוה מלכתחילה. זה פשוט בגלל שסוגי אירועים הם תכונת ליבה של כל יישום webhook, מכיוון שאתה צריך ליידע את המשתמשים איזה אירוע הם מקבלים. באופן מוזר, אימוץ סוג אירועים היה נמוך מאוד עבור סטארט-אפים בינה מלאכותית. ב-API 100, ההטמעות היחידות ללא webhooks היו אלה עם אירוע אחד בלבד, אז אולי לחברות בינה מלאכותית יש רק אירוע אחד להציע. אימות הודעה שוב, אנו רואים עלייה באימוץ שיטות עבודה מומלצות לאימות הודעות (HMACSHA256). אנו רואים שהעלייה הזו מגיעה באופן שווה יחסית מירידה בכל שיטות האימות האלטרנטיביות, אבל במיוחד מיישומים שפשוט העבירו אסימון של Bearer. אימוץ HMACSHA256 דומה בכל רחבי הלוח. התוצאות החריגות מגיעות מה-AI 50 שבו העברת סוד ישירות בכותרת פופולרית מאוד. באופן מעניין, זה מסביר עד כמה מעטים מה-AI 50 אינם מציעים אימות webhook כלל. אישור הודעה: חותמות זמן הכללת חותמת הזמן כחלק מהתוכן הגיבוב בעת יצירת חתימות HMAC עוזרת למנוע התקפות שידור חוזר. ללא חותמת הזמן כחלק מהחתימה, ניתן לשכפל הודעות ישנות ולשלוח אותן שוב, מה שיכול להיות בעיה מרכזית אם מוסד פיננסי מעבד את אותה עסקה פעמיים. עוד מאותו הדבר עם חותמות זמן בחתימה. ספקי API מבוססים מתגברים על חברות סטארט-אפ בכל הנוגע ליישום שיטות עבודה מומלצות. תיעוד תיעוד טוב הוא קריטי כדי לספק חווית מפתח מעולה. זה נכון במיוחד עבור webhooks שיש להם כמה "מלכודות" שמפתחים יכולים ליפול אליהם כאשר מנסים ליישם את נקודות הקצה שלהם. תיעוד נרחב יכול לעזור למשתמשים להימנע מהמלכודות הללו ולחסוך הרבה זמן ותסכול. דבר אחד שאנו רואים משירותי ה-webhook הטובים ביותר הוא הוראות בדיקה. זה כולל גם עצות לפתרון בעיות עבור בעיות נפוצות כמו אימות חתימה נכשל. כשזה מגיע לתיעוד, סטארט-אפים עומדים בקנה אחד עם ספקי webhook מבוססים יותר. זה גם הגיוני מכיוון שהתיעוד הוא בסיסי לכל המוצרים. מרכיב מפתח שאנו רואים כאינדיקטור לתיעוד טוב של webhook הוא דוגמאות קוד. זה חל על רוב תיעוד ה-API אך במיוחד עבור webhooks. שימושי ביותר לקבל דוגמאות לנקודות קצה עובדות של webhook כדי שמשתמשים יבינו בדיוק מה נקודות הקצה שלהם צריכים לעשות וכיצד לעשות זאת. יחד עם כל מה שראינו בדוח עד כה, ראינו גם דוגמאות קוד נוספות. זהו שיקוף ישיר של הגידול במספר הספקים המציעים אימות חתימות HMAC. אם ספקים אינם מציעים אימות כלל או מציעים שיטות פשוטות יותר כמו אימות בסיסי או כותרת סודית פשוטה, יש פחות צורך בדגימת קוד מכיוון שהיישום הוא הרבה יותר פשוט. כאן רוב ספקי ה-webhook, בין אם מבוססים או סטארט-אפים, מציעים דוגמאות קוד למשתמשים שלהם. היוצא מן הכלל הוא עם חברות בינה מלאכותית אשר נוטות לא להציע חתימות של HMAC ולנטוות לכותרות סודיות לאימות. אולי משתמשי AI אינם מודעים לטכניים או לאבטחה כמו צרכני Fintech ו-Devtool ושיטת אימות פשוטה יותר היא הטובה ביותר למקרה השימוש שלהם. נראה גם סביר שלמוצרי AI יש בסיס משתמשי ליבה של צרכנים וממשקי ה-API וה-webhooks שלהם הם הצעה משנית לאחוז קטן מהמשתמשים שלהם ולכן הושקע פחות מאמצים בהפיכת שירותי ה-webhook שלהם לאבטחים/חזקים יותר. סיכום וממצאים מרכזיים אנו שמחים לדווח כי לאחר עדכון המחקר שלנו, ראינו עלייה בכל רחבי האימוץ הכללי, כמו גם יישום של שיטות עבודה מומלצות. ראינו שמספר המאמצים החדשים היה עקבי בכל שיטות העבודה המומלצות, מה שהראה שרוב האימוץ המוגבר הגיע מיישומים חדשים שעקבו אחר רוב השיטות המומלצות, בניגוד להטמעות קיימות המשדרגות את שירותי ה-webhook שלהם. השנה ניתחנו עוד 150 חברות מ-3 רשימות סטארט-אפ מובילות שונות בתחום Fintech, Devtools ו-AI כדי לראות אם נוכל למצוא מגמות כלשהן בין תעשיות, כמו גם הבדלים בין סטארט-אפים לספקי API מבוססים. באופן כללי ראינו שספקי ה-API המבוססים מאמצים webhooks בקצב גבוה יותר וגם מיישמים יותר שיטות עבודה מומלצות. זה מאוד הגיוני מכיוון שלספקים המבוססים יש יותר משאבים להשקיע כדי להציע פתרון טוב יותר וסביר יותר שהסטארט-אפים ישיקו גרסאות MVP (מינימום קיימא) של שירותי ה-webhook שלהם.
