Webhookはどう機能しますか？
データを持つシステムにURL（エンドポイント）を登録し、どのイベントに関心があるかを伝えます。そのイベントのいずれかが起きると、そのシステムは、何が起きたかを記したペイロード（通常はJSON）を付けて、エンドポイントにHTTP POSTを送ります。サーバーはペイロードを読んで処理を行い、受信を知らせるために2xxのステータスを返します。こちらからのリクエストがきっかけではなく、送信元が自発的に送ったものです。ほとんどのプロバイダーは各リクエストに署名しており、本当にそのプロバイダーから届いたものかを確認できます。
WebhookとAPIのポーリング：何が違うのか？
ポーリングはプル型です。何か変化があったかどうかに関係なく、コードが決まった間隔でAPIに「何か新しいものは？」と尋ねます。Webhookはプッシュ型で、送信元は報告すべきことがあるときだけ呼び出してきます。ポーリングはリクエストの大半が無駄になり、イベントから反応までに遅れが生じます。Webhookは数秒以内に届き、それ以外のときは静かです。その代わり、エンドポイントは公開されていて、急な集中にも耐えられる必要があります。
エンゲージメントプラットフォームはWebhookをどう使いますか？
- 送信側：ジャーニーの中にあるWebhookノードが、フローの途中で外部システムにPOSTします。リードがコンバージョンしたらSlackに通知する、ステータスをCRMに同期する、フルフィルメント処理を開始する、といった用途です。
- 受信側：レシーバーがほかのツールからのイベントを取り込みます。決済プロバイダーが支払いの成功を報告し、フォームツールが新しいリードを渡すことで、夜間のインポートを待たずにプロファイルとジャーニーが反応します。
- この双方向の配管があるからこそ、カスタマーエンゲージメントプラットフォームはスタックの中心に位置できます。Knockのような配信専用のサービスは、送信側だけに特化しています。
小さなチームにとってなぜ重要か
2人のチームでは、張り付いて変化を確認し続けることはできません。また、数分おきに確認するcronジョブは遅れとコストの両方を生みます。Webhookがあれば、誰も見ていなくても、何かが起きた瞬間にあるツールが別のツールに反応できます。注意点は2つです。公開URLには誰でもPOSTできるため、すべてのリクエストで署名を検証し、本文は信頼できないものとして扱います。そして、送受信するイベントをログに残し、記録されない裏ルートにせず、トラッキングプランと整合させます。