Webhooks
Resumen
Puedes configurar determinados eventos de ElevenLabs para que activen webhooks, lo que permite a aplicaciones y sistemas externos recibir y procesar estos eventos cuando se producen. Los tipos de eventos compatibles actualmente incluyen:
Configuración
Puedes crear, desactivar y eliminar webhooks desde la página de ajustes generales. Para usuarios de Espacios de trabajo, solo los administradores del espacio de trabajo pueden configurar sus webhooks.

Después de crearlo, puedes seleccionar el webhook para que escuche eventos en ajustes de productos como Agents Platform.
Los eventos flows_generation y flows_template_run se activan con una única suscripción: en Selecciona los eventos que quieres escuchar, marca Generación o ejecución de plantilla de la API de Imagen y Video completada, o envía el evento flows a Actualizar webhook del espacio de trabajo. Una generación o ejecución solo envía su evento si su solicitud de creación incluye un campo webhook.
Puedes desactivar los webhooks desde la página de ajustes generales en cualquier momento. Los webhooks que fallan repetidamente se desactivan automáticamente si hay 10 o más fallos consecutivos y la última entrega correcta se realizó hace más de 7 días, o nunca se ha entregado correctamente. Los webhooks desactivados automáticamente deben volver a activarse desde la página de ajustes. Puedes eliminar webhooks si ningún producto los utiliza.
Reintentos
Puedes activar los reintentos de webhook para cada webhook, de modo que se vuelva a intentar la entrega automáticamente cuando falle una solicitud. Los reintentos están desactivados de forma predeterminada. Actívalos al crear o actualizar un webhook mediante la API o en los ajustes del webhook.
Los reintentos son compatibles con los webhooks posteriores a la llamada
de ElevenAgents, incluidos los eventos de transcripción
(post_call_transcription), audio (post_call_audio) y fallo al iniciar la llamada
(call_initiation_failure).
Calendario de reintentos
Cuando un intento de entrega falla con un error que permite reintento, el sistema lo vuelve a intentar hasta 5 veces, con retrasos crecientes entre intentos:
Se añade una pequeña variación aleatoria (de hasta el 10 % del retraso) a cada reintento para distribuir la carga y evitar problemas de avalanchas de solicitudes.
Errores que permiten reintento
No todos los fallos activan un reintento. Solo se consideran reintentables los siguientes fallos:
- Códigos de estado
5xx(errores de servidor como 500, 502, 503, 504). 429(demasiadas solicitudes).408(tiempo de espera de la solicitud).- Errores de conexión y tiempos de espera de solicitudes.
Los errores de solicitud del rango 4xx (como 400, 401, 403, 404) no se reintentan, ya que normalmente indican un problema de configuración que requiere corrección manual.
Límites de cola por webhook
Cada webhook está limitado a 100 tareas de reintento pendientes. Si un webhook acumula más de 100 reintentos en cola, se descartan las tareas adicionales hasta que se procesen los reintentos existentes. Esto evita que un único webhook mal configurado consuma recursos excesivos.
Los webhooks de audio tienen dos límites adicionales. Una carga útil de audio superior a 50 MiB se entrega una vez y no se vuelve a intentar, y los reintentos de audio en cola de un solo webhook no pueden superar 400 MiB en total.
Comportamiento de desactivación automática
El sistema registra los fallos de entrega consecutivos de cada webhook. Un webhook se desactiva automáticamente cuando se cumplen ambas condiciones siguientes:
- Se han producido 10 o más fallos de entrega consecutivos.
- El webhook nunca se ha entregado correctamente o la última entrega correcta se realizó hace más de 7 días.
Cuando un webhook se desactiva automáticamente, los administradores del espacio de trabajo reciben una notificación por correo electrónico. Debes volver a activar manualmente el webhook desde la página de ajustes antes de que reanude las entregas.
Integración
Para integrar webhooks, crea un controlador de ruta que reciba los datos de eventos de webhook como solicitudes POST. Tras validar la firma, el controlador debe devolver HTTP 200 rápidamente para indicar que se ha recibido correctamente. No devolver repetidamente una respuesta correcta puede provocar que el webhook se desactive automáticamente.
La carga útil del reintento es idéntica a la del intento de entrega original. Los consumidores de webhooks no pueden distinguir entre una entrega inicial y un reintento solo a partir de la carga útil, así que diseña tu controlador para que sea idempotente: procesar el mismo evento varias veces debe producir el mismo resultado. Usa event_timestamp e identificadores específicos del evento (como conversation_id) para eliminar eventos duplicados si es necesario.
Campos de nivel superior
Ejemplo de carga útil de webhook
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: