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

通話後Webhookが成功したと見なされるには、200ステータスコードを返す必要があります。10回以上連続して失敗し、最後に配信に成功してから7日以上経過しているか、一度も配信に成功していない場合、繰り返し失敗するWebhookは自動的に無効になります。
通話後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オブジェクトの構造
dataオブジェクトには次のフィールドが含まれます。
オーディオWebhook(post_call_audio)
会話全体のオーディオをbase64エンコード済みMP3として含む、最小限のデータです。
トップレベルフィールド
dataオブジェクトの構造
dataオブジェクトには、次のフィールドのみが含まれます。
オーディオWebhookには、上記のフィールドのみが含まれます。文字起こしデータ、メタデータ、分析結果、その他の会話の詳細は含まれません。
通話開始失敗Webhook(call_initiation_failure)
失敗理由や電話通信プロバイダーのメタデータなど、電話通話の開始試行に関する情報が含まれます。
接続エラー、ユーザーによる着信拒否、ユーザーが応答しなかったことが原因で通話を開始できなかった場合、通話開始失敗Webhookイベントが送信されます。留守番電話につながった場合や自動応答サービスが応答した場合は、通話が正常に開始されているため、通話開始失敗Webhookは送信されません。
トップレベルフィールド
dataオブジェクトの構造
dataオブジェクトには次のフィールドが含まれます。
Twilio経由の発信通話では、failure_reasonはTwilioのCallStatusから導出されます。busyとno-answerはそのまま渡され、failedはunknownとして報告されます。Twilioのその他の通話ステータスでは、通話開始失敗Webhookは送信されません。
metadataオブジェクトの構造
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}}動的変数として新しい会話に渡せます。 - これにより、エージェントが過去のやり取りを「記憶」しているようなシームレスな体験を実現できます