Webhooks posteriores a la llamada
Recibe notificaciones cuando terminan las llamadas y se completa el análisis mediante webhooks.
Resumen
Los webhooks posteriores a la llamada te permiten recibir información detallada sobre una llamada tras completarse el análisis. Cuando están activados, ElevenLabs enviará una solicitud POST a la ruta que especifiques con datos completos de la llamada.
ElevenLabs admite tres tipos de webhooks posteriores a la llamada:
- Webhooks de transcripción (
post_call_transcription): contienen los datos completos de la conversación, incluidas las transcripciones, los resultados del análisis y los metadatos. - Webhooks de audio (
post_call_audio): contienen datos mínimos con el audio de toda la conversación codificado en base64. - Webhooks de error al iniciar una llamada (
call_initiation_failure): contienen información sobre intentos fallidos de iniciar llamadas, incluidos los motivos del error y los metadatos.
Activar webhooks posteriores a la llamada
Puedes activar los webhooks posteriores a la llamada para todos los agentes de tu espacio de trabajo desde la página de configuración de ElevenAgents.

Los webhooks posteriores a la llamada deben devolver un código de estado 200 para considerarse correctos. Los webhooks que fallan de forma reiterada se desactivan automáticamente si tienen 10 o más fallos consecutivos y la última entrega correcta fue hace más de 7 días o nunca se han entregado correctamente.
Los webhooks posteriores a la llamada pueden reintentarse automáticamente si fallan. Consulta los reintentos de webhooks.
Autenticación
Es importante que el listener valide todos los webhooks entrantes. Actualmente, los webhooks admiten autenticación mediante firmas HMAC. Configura la autenticación HMAC de esta forma:
- Almacena de forma segura el secreto compartido generado al crear el webhook
- Verifica la cabecera ElevenLabs-Signature en tu ruta de API mediante el SDK
El SDK de JavaScript incluye constructEvent; el SDK de Python incluye construct_event con rawBody, sig_header y secret (en Python no se llaman payload / signature). Ambos verifican la firma, validan la marca de tiempo y analizan la carga útil JSON.
Python
JavaScript
Ejemplo de controlador de webhook con FastAPI:
Encabezados de solicitud personalizados
Además de la validación de firma HMAC, puedes incluir encabezados personalizados en cada entrega de webhook. Esto resulta útil para enviar claves de API, tokens bearer u otros encabezados de autenticación que requiera la ruta receptora.
Panel de control
CLI
SDK
Actualmente no es posible configurar encabezados personalizados desde el panel de control de ElevenAgents. Usa el SDK o la API para configurar encabezados personalizados.
Los encabezados personalizados funcionan junto con la autenticación HMAC. auth_type debe seguir establecido en hmac
y los encabezados personalizados se envían además del encabezado ElevenLabs-Signature.
Los encabezados personalizados son de solo escritura. La ruta para listar webhooks
no devuelve request_headers en su respuesta, por lo que no puedes consultar qué encabezados están
configurados para un webhook.
Listas de IP permitidas
Para mayor seguridad, puedes añadir las IP de salida estáticas de ElevenLabs a tu lista de IP permitidas. Consulta listas de IP permitidas para ver la lista completa de direcciones IP.
Usar una lista de IP permitidas junto con la validación de firma HMAC proporciona varias capas de seguridad.
Anulaciones de webhook por agente
De forma predeterminada, todos los agentes de tu espacio de trabajo usan el webhook configurado en los ajustes del espacio de trabajo. Puedes anularlo para cada agente y enviar datos posteriores a la llamada a rutas distintas para agentes diferentes.
Panel de control
CLI
SDK
Abre los ajustes del agente
Ve a tu agente en el panel de control de ElevenAgents y accede a Ajustes.
post_call_webhook_id debe hacer referencia a un webhook que ya exista en tu espacio de trabajo. También puedes especificar qué tipos de eventos enviar mediante la matriz events:
Estructura de la respuesta del webhook
ElevenLabs envía tres tipos distintos de webhooks posteriores a la llamada, cada uno con estructuras de datos diferentes:
Webhooks de transcripción (post_call_transcription)
Contienen datos completos de la conversación, incluidas las transcripciones completas, los resultados del análisis y los metadatos.
Campos de nivel superior
Estructura del objeto de datos
El objeto data contiene:
Webhooks de audio (post_call_audio)
Contienen datos mínimos con el audio completo de la conversación como MP3 codificado en base64.
Campos de nivel superior
Estructura del objeto de datos
El objeto data contiene únicamente:
Los webhooks de audio contienen únicamente los campos indicados arriba. NO incluyen datos de transcripción, metadatos, resultados del análisis ni ningún otro detalle de la conversación.
Webhooks de error al iniciar una llamada (call_initiation_failure)
Contienen información sobre intentos de iniciar llamadas de telefonía, incluidos los motivos del error y los metadatos del proveedor de telefonía.
Los eventos de webhook de error al iniciar una llamada se envían cuando una llamada no puede iniciarse por errores de conexión, porque el usuario rechaza la llamada o porque no descuelga. Si una llamada va al buzón de voz o la responde un servicio automatizado, no se envía ningún webhook de error al iniciar la llamada, ya que esta se inició correctamente.
Campos de nivel superior
Estructura del objeto de datos
El objeto data contiene:
Para las llamadas salientes realizadas mediante Twilio, failure_reason se deriva de CallStatus de Twilio: busy y no-answer se transfieren sin cambios, y failed se comunica como unknown. Otros estados de llamada de Twilio no envían un webhook de error al iniciar una llamada.
Estructura del objeto de metadatos
La estructura del objeto metadata varía según si la llamada saliente se realizó mediante Twilio o mediante trunking SIP. El objeto incluye un campo type que distingue entre ambos y un campo body con detalles específicos del proveedor.
Metadatos SIP (type: "sip"):
El objeto body de los metadatos SIP contiene:
Metadatos de Twilio (type: "twilio"):
Ejemplos de cargas útiles de webhook
Ejemplo de webhook de transcripción
Ejemplo de webhook de audio
Ejemplos de webhooks de error al iniciar una llamada
Ejemplo de metadatos de Twilio
Ejemplo de metadatos SIP
Entrega de webhooks de audio
Los webhooks de audio se entregan por separado de los webhooks de transcripción y contienen únicamente los campos esenciales para identificar la conversación, junto con los datos de audio codificados en base64.
Puedes activar o desactivar los webhooks de audio con el interruptor “Enviar datos de audio” en los ajustes de tu webhook. Este ajuste puede configurarse tanto a nivel del espacio de trabajo (en los ajustes de ElevenAgents) como a nivel del agente (en las anulaciones de webhook de cada agente).
Entrega en streaming
Los webhooks de audio se entregan como solicitudes HTTP en streaming con el encabezado transfer-encoding: chunked para gestionar archivos de audio grandes de forma eficiente. Cada solicitud agota el tiempo de espera después de 5 minutos.
Reintentos
Cuando los reintentos están activados en el webhook, las entregas de audio fallidas se reintentan con la misma programación que los webhooks de transcripción. Un reintento reenvía la carga útil de audio completa, así que elimina duplicados mediante conversation_id. Consulta reintentos de webhooks para ver la programación, los errores que permiten reintentos y los límites de tamaño de audio.
Procesar webhooks de audio
Como los webhooks de audio se entregan mediante codificación de transferencia por fragmentos, tendrás que gestionar correctamente los datos en streaming:
Los webhooks de audio pueden ser archivos grandes, así que asegúrate de que la ruta de tu webhook puede gestionar solicitudes en streaming y cuenta con suficiente capacidad de memoria y almacenamiento. El audio se entrega en formato MP3.
Casos de uso
Seguimientos automáticos de llamadas
Los webhooks posteriores a la llamada te permiten crear flujos de trabajo automatizados que se activan inmediatamente después de que termine una llamada. Estas son algunas aplicaciones prácticas:
Integración con CRM
Actualiza tu sistema de gestión de relaciones con clientes con los datos de la conversación en cuanto termine una llamada:
Conversaciones con estado
Mantén el contexto de la conversación entre varias interacciones almacenando y recuperando el estado:
- Cuando se inicia una llamada, pasa el id de usuario como variable dinámica.
- Cuando termina una llamada, configura la ruta de tu webhook para almacenar los datos de la conversación en tu base de datos, según el id de usuario extraído de dynamic_variables.
- Cuando el usuario vuelva a llamar, puedes recuperar este contexto y pasarlo a la nueva conversación en una variable dinámica
{{previous_topics}}. - Esto crea una experiencia fluida en la que el agente “recuerda” interacciones anteriores.