2024 年 Webhook の現状レポート

2023 年、当社は上位 100 社の API 企業と Svix の社内データを調べ、業界全体で Webhook のベスト プラクティスがどのくらいの頻度で実装されているか、またこれらのプラクティスが Webhook システムの信頼性とスケーラビリティにどのような影響を与えているかを調査しました。

今年、私たちは同じ 100 社を調査し、Webhook の採用と実装のベスト プラクティスが増加したかどうか、またどの程度増加したかを調べました。また、Fintech、開発者ツール、AI の 3 つの異なる業界で Forbes によってスタートアップとして分類された 100 社を超える新しい企業を調査し、業界間および会社の段階別に Webhook の採用率を比較しました。

ウェブフックの採用とベストプラクティスの実装が全体的に増加していることをお知らせできて大変うれしく思います。この傾向の大きな要因の 1 つは、アウトバウンドウェブフックサービスのベストプラクティスを概説した標準ウェブフック仕様のリリースと、ウェブフックの消費者からの信頼性とセキュリティの高いウェブフックに対する継続的な需要であると考えています。

Webhookの導入

昨年、私たちが分析した上位 100 個の API のうち 83 個が Webhook を提供していました。今年、同じ 100 個の API を調べたところ、Webhook の採用率はわずかに増加して 85% でした。

今回の State of Webhooks で答えたかった質問の 1 つは、スタートアップが既存の API プロバイダーよりも Webhook サービスを提供する可能性が高いか低いかということでした。一方で、スタートアップは新しいテクノロジーをより早く採用する傾向がありますが、Webhook は API のリリース後に追加される機能である傾向があります。

私たちは、Forbes Fintech 50 および AI 50 リスト、および Failory のトップ 59 DevTool スタートアップ リストからスタートアップを取り上げ、API トップ 100 と同じ方法で分析しました。明らかに、スタートアップは Webhook の採用で少し遅れをとっており、特に消費者中心のビジネスになりがちな AI ではその傾向が顕著です。

再試行

再試行 (試行が失敗した場合に Webhook を再送信すること) は、信頼性の高い Webhook システムの基本コンポーネントの 1 つであるため、採用率が 67% から 73% に増加したことを嬉しく思います。

また、再試行回数も増加しており、再試行回数を 1 回のみ提供するサービスの数は減少し、再試行回数を 5 回以上提供するサービスの数は増加しています。

スタートアップが全体的な Webhook の採用で遅れているのと同様に、再試行の採用でも遅れています。特に Devtool のスタートアップでは採用率が大幅に低く、これは予想外でした。

フィンテックは再試行の採用率が最も高く、これは金融イベントにリアルタイムで対応し、取引データを見逃したり失ったりしないことがいかに重要であるかを考えると当然のことです。

再試行: 指数バックオフ

再試行間の待機時間を徐々に増やすことで、サーバーの問題が悪化するリスクが軽減され、最初の数回の再試行を迅速に送信することで一時的な問題に対処し、ユーザーに障害が発生したエンドポイントを修正するための十分な時間を与えることができます。

再試行のための指数バックオフ スケジュールの採用も 25/83 (30%) から 31/83 (37%) に増加しました。

スタートアップにおける指数バックオフの採用に関する話は、全体的な再試行の採用と非常に似ています。Fintech スタートアップが先頭を走っていますが、Devtool スタートアップは大幅に遅れています。

手動再試行

％ベースで見ると、分析したすべてのベストプラクティスの中で、採用率が最も上昇したのは手動再試行の実装（+71％）でした。もちろん、これは2023年のレポートで最も採用率の低いベストプラクティスであり、改善の余地が最も大きかったものです。

メッセージを手動で再試行できると、トラブルシューティングが高速化されます。次の自動再試行を待つのではなく、再試行をすぐにトリガーする方が高速です。

これは素晴らしい傾向であり、障害が発生したエンドポイントのトラブルシューティングや、初期セットアップおよびテスト中にテスト イベントを送信する必要がある場合に、Webhook の消費者の作業が大幅に楽になるはずです。

最も驚くべき結果の 1 つは、AI スタートアップが手動再試行を採用する割合でした。他のベスト プラクティスと比較して、Fintech スタートアップの採用率が非常に低い理由として、金融システムでは通常大量のメッセージが存在するため、単一のトランザクションを再試行する機能がほとんど必要ないことが考えられます。

メッセージの量が多い場合は通常、失敗したメッセージをすべて一括またはバッチで再試行する必要があります。AI 製品では、メッセージ量が少なくなる傾向があります。

ログ記録と監視

もう一つの大きな増加率は、メッセージ履歴ログを提供するサービスの数です。これは、障害が発生したエンドポイントのトラブルシューティングをユーザーがセルフサービスで実行できる優れた機能です。

これにより、期待したイベントを受信できない理由についてのサポートからの応答を待つ必要がなくなるため、消費者にとってメリットがあるだけでなく、Webhook プロバイダーにとっても、Webhook の失敗に関するサポート リクエストが大幅に減少するためメリットがあります。

開発者が問題を自己診断できれば、問題もより早く解決されるため、この機能は誰にとってもメリットがあります。

イベントの種類

もう 1 つの興味深い結果は、メッセージのログ記録と監視の採用が、上位 100 の API プロバイダーとスタートアップの間でも、また業界全体でもほぼ均等であるということです。

これは、障害を自己診断してトラブルシューティングする能力が、特定の分野や企業の段階に特有のものではなく、すべての Webhook ユーザーが求め、大きなメリットを享受できるものであることを示しています。

イベント タイプの採用率は、採用率がもともと高かったため、基本的に同じでした (93% 対 94%)。これは、ユーザーが受信するイベントを知らせる必要があるため、イベント タイプが Webhook 実装のコア機能であるためです。

興味深いことに、AI スタートアップ企業ではイベント タイプの採用が非常に少なかった。API 100 では、Webhook のない実装はイベントが 1 つだけのものだけだったので、AI 企業が提供できるイベントは 1 つだけなのかもしれない。

メッセージ認証

ここでも、メッセージ認証のベスト プラクティス (HMACSHA256) の採用が増加しています。この増加は、すべての代替認証方法の減少から比較的均等に生じていますが、特に Bearer トークンを単に渡す実装から生じています。

HMACSHA256 の採用は全体的に似ています。例外的な結果は、ヘッダーでシークレットを直接渡すことが非常に一般的である AI 50 から得られます。興味深いことに、これにより、Webhook 認証をまったく提供していない AI 50 がほとんどないことが説明できます。

メッセージ認証: タイムスタンプ

HMAC 署名を生成する際にハッシュ化されたコンテンツの一部としてタイムスタンプを含めると、リプレイ攻撃を防ぐのに役立ちます。署名の一部としてタイムスタンプがないと、古いメッセージが複製されて再送信される可能性があり、金融機関が同じトランザクションを 2 回処理する場合に重大な問題となる可能性があります。

署名にタイムスタンプが付いている点も同様です。ベストプラクティスの実装に関しては、確立された API プロバイダーがスタートアップ企業よりも優れています。

ドキュメント

優れた開発者エクスペリエンスを提供するには、適切なドキュメントが不可欠です。これは、エンドポイントを実装しようとするときに開発者が陥る可能性のあるいくつかの「罠」がある Webhook の場合に特に当てはまります。詳細なドキュメントがあれば、ユーザーはこれらの落とし穴を回避し、多くの時間とフラストレーションを節約できます。

最高の Webhook サービスに見られる特徴の 1 つは、テストに関する指示です。これには、署名検証の失敗などの一般的な問題に対するトラブルシューティングのヒントも含まれます。

ドキュメントに関しては、スタートアップ企業はより確立された Webhook プロバイダーと同等です。ドキュメントはすべての製品の基礎となるため、これも当然のことです。

優れた Webhook ドキュメントの指標として私たちが考える重要な要素は、コード サンプルです。これはほとんどの API ドキュメントに当てはまりますが、特に Webhook に当てはまります。ユーザーがエンドポイントで何を行う必要があるか、またそれをどのように行うかを正確に理解するには、動作する Webhook エンドポイントの例があると非常に役立ちます。

これまでのレポートで確認した他のすべてのことに加え、コード サンプルも増えました。これは、HMAC 署名認証を提供するプロバイダーの数が増えたことを直接反映しています。プロバイダーが認証をまったく提供していない場合や、基本認証や単純なシークレット ヘッダーなどのより簡単な方法を提供している場合は、実装がはるかに簡単なので、コード サンプルの必要性は低くなります。

ここでは、既存のものでも新興のものでも、ほとんどの Webhook プロバイダーがユーザーにコード サンプルを提供しています。例外は AI 企業で、HMAC 署名を提供せず、認証に秘密のヘッダーを使用する傾向があります。

おそらく、AI ユーザーは Fintech や Devtool の消費者ほど技術やセキュリティに敏感ではなく、よりシンプルな認証方法が彼らのユースケースには最適です。また、AI 製品には消費者というコア ユーザー ベースがあり、その API と Webhook は少数のユーザー向けの二次的なサービスであるため、Webhook サービスをより安全かつ堅牢にするための努力があまり行われていないようです。

要約と主な調査結果

調査を更新した後、一般的な採用とベストプラクティスの実装が全体的に増加していることを報告できてうれしく思います。

新規導入者の数はすべてのベスト プラクティスにわたって一貫しており、導入の増加のほとんどが、既存の実装で Webhook サービスをアップグレードしたのではなく、ベスト プラクティスのほとんどに従った新しい実装によるものであることがわかりました。

今年は、フィンテック、開発ツール、AI の 3 つの異なるトップスタートアップ リストからさらに 150 社を分析し、業界間の傾向や、スタートアップと既存の API プロバイダー間の違いが見つかるかどうかを調べました。

一般的に、確立された API プロバイダーは Webhook をより多く採用し、より多くのベスト プラクティスを実装していることがわかりました。これは非常に論理的です。確立されたプロバイダーはより優れたソリューションを提供するために投資するリソースが多く、スタートアップは Webhook サービスの MVP (最小限の実行可能な製品) バージョンをリリースする可能性が高いためです。