通話後Webhook
通話が終了し、分析が完了した際にWebhookで通知を受け取ります。
概要
通話後のWebhookを使用すると、分析完了後に通話に関する詳細情報を受け取れます。有効にすると、ElevenLabsは包括的な通話データを含むPOSTリクエストを指定したエンドポイントに送信します。
ElevenLabsは、次の3種類の通話後Webhookをサポートしています。
- 文字起こしWebhook(
post_call_transcription):文字起こし、分析結果、メタデータを含む完全な会話データ - 音声Webhook(
post_call_audio):会話全体のBase64エンコード済み音声を含む最小限のデータ - 通話開始失敗Webhook(
call_initiation_failure):失敗理由やメタデータを含む、通話開始に失敗した試行に関する情報
通話後Webhookを有効にする
通話後Webhookは、ElevenAgentsの設定ページからワークスペース内のすべてのエージェントに対して有効にできます。

通話後Webhookが成功とみなされるには、200ステータスコードを返す必要があります。Webhookは、10回以上連続して失敗し、最後の 配信成功から7日以上経過しているか、一度も正常に配信されていない場合、自動的に無効になります。
通話後Webhookは、失敗した場合に自動で再試行できます。詳しくはWebhookの 再試行を参照してください。
認証
受信側は、すべての受信Webhookを検証することが重要です。Webhookは現在、HMAC署名による認証に対応しています。HMAC認証は次の手順で設定します。
- Webhookの作成時に生成された共有シークレットを安全に保存する
- SDKを使用してエンドポイントでElevenLabs-Signatureヘッダーを検証する
JavaScript SDKではconstructEventを、Python SDKでは**rawBody、sig_header、secret**を指定するconstruct_eventを利用できます(Pythonではpayload/signatureという名前ではありません)。どちらも署名の検証、タイムスタンプの検証、JSONペイロードの解析を行います。
Python
JavaScript
FastAPIを使用したWebhookハンドラーの例:
カスタムリクエストヘッダー
HMAC署名検証に加えて、Webhookの配信ごとにカスタムヘッダーを含めることができます。これは、受信エンドポイントで必要となるAPIキー、Bearerトークン、その他の認証ヘッダーを渡す場合に便利です。
ダッシュボード
CLI
SDK
ElevenAgentsダッシュボードでは、現在カスタムヘッダーを設定できません。SDKまたはAPIを使用してカスタムヘッダーを設定してください。
カスタムヘッダーはHMAC認証と併用できます。auth_typeは引き続きhmacに設定する必要があり、
カスタムヘッダーはElevenLabs-Signatureヘッダーに加えて送信されます。
カスタムヘッダーは書き込み専用です。Webhook一覧エンドポイントの
レスポンスにはrequest_headersが返されないため、Webhookに設定されているヘッダーを
読み戻すことはできません。
IP許可リスト
セキュリティを強化するため、ElevenLabsの静的エグレスIPを許可リストに追加できます。IPアドレスの完全な一覧は、IP許可リストを参照してください。
IP許可リストをHMAC署名検証と組み合わせることで、複数層のセキュリティを提供できます。
エージェントごとのWebhookオーバーライド
デフォルトでは、ワークスペース内のすべてのエージェントが、ワークスペース設定で構成されたWebhookを使用します。エージェントごとにこれをオーバーライドし、異なるエージェントの通話後データを異なるエンドポイントへ送信できます。
ダッシュボード
CLI
SDK
post_call_webhook_idは、ワークスペース内にすでに存在するWebhookを参照する必要があります。events配列を使用して、送信するイベントタイプを指定することもできます。
Webhookレスポンスの構造
ElevenLabsは、データ構造がそれぞれ異なる3種類の通話後Webhookを送信します。
文字起こしWebhook(post_call_transcription)
完全な文字起こし、分析結果、メタデータを含む包括的な会話データを提供します。
トップレベルフィールド
データオブジェクトの構造
dataオブジェクトには次が含まれます。
音声Webhook(post_call_audio)
会話全体のBase64エンコード済みMP3音声を含む最小限のデータを提供します。
トップレベルフィールド
データオブジェクトの構造
dataオブジェクトには、次のみが含まれます。
音声Webhookには、上記の3つのフィールドのみが含まれます。文字起こしデータ、メタデータ、 分析結果、その他の会話の詳細は含まれません。
通話開始失敗Webhook(call_initiation_failure)
失敗理由や電話プロバイダーのメタデータなど、電話通話の開始試行に関する情報を提供します。
通話開始失敗Webhookイベントは、接続エラー、ユーザーによる通話拒否、またはユーザーが応答しなかったことにより 通話の開始に失敗した場合に送信されます。通話が留守番電話につながった場合や自動サービスが応答した場合、通話は 正常に開始されているため、通話開始失敗Webhookは送信されません。
トップレベルフィールド
データオブジェクトの構造
dataオブジェクトには次が含まれます。
Twilio経由の発信通話では、failure_reasonはTwilioのCallStatusから導出されます。busyとno-answerはそのまま渡され、failedはunknownとして報告されます。その他のTwilio通話ステータスでは、通話開始失敗Webhookは送信されません。
メタデータオブジェクトの構造
metadataオブジェクトの構造は、発信通話がTwilio経由かSIPトランキング経由かによって異なります。このオブジェクトには、両者を区別するtypeフィールドと、プロバイダー固有の詳細を含むbodyフィールドがあります。
SIPメタデータ(type: "sip"):
SIPメタデータのbodyオブジェクトには次が含まれます。
Twilioメタデータ(type: "twilio"):
Webhookペイロードの例
文字起こしWebhookの例
音声Webhookの例
通話開始失敗Webhookの例
Twilioメタデータの例
SIPメタデータの例
音声Webhookの配信
音声Webhookは文字起こしWebhookとは別に配信され、会話を識別するために必要な基本フィールドと、Base64エンコード済み音声データのみを含みます。
音声Webhookは、Webhook設定の「音声データを送信」トグルで有効または無効にできます。この設定は、 ワークスペースレベル(ElevenAgents設定内)とエージェントレベル(個別のエージェントWebhookオーバーライド内)の両方で 構成できます。
ストリーミング配信
音声Webhookは、大きな音声ファイルを効率的に処理するため、transfer-encoding: chunkedヘッダーを使用するストリーミングHTTPリクエストとして配信されます。各リクエストは5分後にタイムアウトします。
再試行
Webhookで再試行が有効になっている場合、失敗した音声配信は文字起こしWebhookと同じスケジュールで再試行されます。再試行では完全な音声ペイロードが再送されるため、conversation_idで重複を排除してください。スケジュール、再試行可能なエラー、音声サイズ制限については、Webhookの再試行を参照してください。
音声Webhookを処理する
音声Webhookはチャンク転送エンコーディングで配信されるため、ストリーミングデータを適切に処理する必要があります。
音声Webhookは大きなファイルになる場合があるため、Webhookエンドポイントがストリーミングリクエストを処理でき、 十分なメモリ/ストレージ容量を持つことを確認してください。音声はMP3形式で配信されます。
ユースケース
自動通話フォローアップ
通話後Webhookを使うと、通話終了直後にトリガーされる自動ワークフローを構築できます。実用的な活用例をいくつか紹介します。
CRMインテグレーション
通話が完了するとすぐに、会話データで顧客関係管理システムを更新します。
ステートフルな会話
状態を保存・取得することで、複数のやり取りにわたって会話コンテキストを維持します。
- 通話を開始するとき、ユーザーIDを動的変数として渡します。
- 通話が終了したら、dynamic_variablesから抽出したユーザーIDに基づいて会話データをデータベースに保存するよう、Webhookエンドポイントを設定します。
- ユーザーが再度通話した際に、このコンテキストを取得し、新しい会話の
{{previous_topics}}動的変数に渡せます。 - これにより、エージェントが以前のやり取りを「記憶」しているようなシームレスな体験を実現できます。