通话后 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 提供 construct_event,并使用 rawBody、sig_header 和 secret(在 Python 中,它们不叫 payload / signature)。两者都会验证签名、验证时间戳,并解析 JSON 负载。
Python
JavaScript
使用 FastAPI 的 webhook 处理程序示例:
IP 允许列表
为提高安全性,可将 ElevenLabs 的静态出口 IP 添加到允许列表。完整 IP 地址列表请参阅 IP 允许列表。
将 IP 允许列表与 HMAC 签名验证结合使用,可提供多层 安全保障。
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 可帮助你构建在通话结束后立即触发的自动化 workflow。以下是一些实际应用:
CRM 集成
通话完成后,立即使用对话数据更新客户关系管理系统:
有状态对话
通过存储和检索状态,在多次交互中保持对话上下文:
- 通话开始时,将用户 ID 作为动态变量传入。
- 通话结束时,将 webhook 端点设置为根据从 dynamic_variables 中提取的用户 ID,把对话数据存储到数据库。
- 用户再次来电时,可以检索此上下文,并将其作为
{{previous_topics}}动态变量传入新对话。 - 这样,智能体就能“记住”之前的互动,提供连贯的体验。