Webhooks pós-chamada
Receba notificações quando as chamadas terminarem e a análise for concluída por meio de webhooks.
Visão geral
Os webhooks pós-chamada permitem que você receba informações detalhadas sobre uma chamada após a conclusão da análise. Quando ativados, a ElevenLabs enviará uma solicitação POST ao endpoint especificado com dados abrangentes da chamada.
A ElevenLabs oferece suporte a três tipos de webhooks pós-chamada:
- Webhooks de transcrição (
post_call_transcription): contêm dados completos da conversa, incluindo transcrições, resultados de análise e metadados - Webhooks de áudio (
post_call_audio): contêm dados mínimos com o áudio da conversa completa codificado em base64 - Webhooks de falha na iniciação de chamada (
call_initiation_failure): contêm informações sobre tentativas de iniciação de chamada que falharam, incluindo motivos da falha e metadados
Como ativar webhooks pós-chamada
Os webhooks pós-chamada podem ser ativados para todos os agentes no seu espaço de trabalho pela página de configurações do ElevenAgents.

Os webhooks pós-chamada precisam retornar um código de status 200 para serem considerados bem-sucedidos. Webhooks que falham repetidamente são desativados automaticamente se houver 10 ou mais falhas consecutivas e a última entrega bem-sucedida tiver ocorrido há mais de 7 dias ou nunca tiver sido entregue com sucesso.
Os webhooks pós-chamada podem ser repetidos automaticamente em caso de falha. Consulte as tentativas de webhook.
Autenticação
É importante que o listener valide todos os webhooks recebidos. Atualmente, os webhooks oferecem suporte à autenticação por assinaturas HMAC. Configure a autenticação HMAC:
- Armazenando com segurança o segredo compartilhado gerado na criação do webhook
- Verificando o cabeçalho ElevenLabs-Signature no seu endpoint usando o SDK
O SDK JavaScript disponibiliza constructEvent; o SDK Python disponibiliza construct_event com rawBody, sig_header e secret (em Python, eles não se chamam payload / signature). Ambos verificam a assinatura, validam o carimbo de data e hora e analisam o payload JSON.
Python
JavaScript
Exemplo de manipulador de webhook usando FastAPI:
Cabeçalhos de solicitação personalizados
Além da validação de assinatura HMAC, você pode incluir cabeçalhos personalizados em cada entrega de webhook. Isso é útil para enviar chaves de API, tokens bearer ou outros cabeçalhos de autenticação exigidos pelo endpoint de recebimento.
Painel
CLI
SDK
Atualmente, os cabeçalhos personalizados não podem ser configurados pelo painel do ElevenAgents. Use o SDK ou a API para definir cabeçalhos personalizados.
Os cabeçalhos personalizados funcionam junto com a autenticação HMAC. O auth_type ainda precisa ser definido como hmac,
e os cabeçalhos personalizados são enviados além do cabeçalho ElevenLabs-Signature.
Os cabeçalhos personalizados são somente para gravação. O endpoint de listagem de webhooks
não retorna request_headers na resposta, portanto você não pode consultar quais cabeçalhos estão
configurados para um webhook.
Lista de permissões de IP
Para mais segurança, você pode adicionar os IPs estáticos de saída da ElevenLabs à sua lista de permissões. Consulte lista de permissões de IP para ver a lista completa de endereços IP.
Usar uma lista de permissões de IP em conjunto com a validação de assinatura HMAC fornece várias camadas de segurança.
Substituições de webhook por agente
Por padrão, todos os agentes do seu espaço de trabalho usam o webhook configurado nas configurações do espaço de trabalho. Você pode substituir essa configuração para cada agente e enviar dados pós-chamada a endpoints diferentes para agentes diferentes.
Painel
CLI
SDK
O post_call_webhook_id precisa referenciar um webhook que já exista no seu espaço de trabalho. Você também pode especificar quais tipos de evento enviar usando o array events:
Estrutura da resposta do webhook
A ElevenLabs envia três tipos distintos de webhooks pós-chamada, cada um com estruturas de dados diferentes:
Webhooks de transcrição (post_call_transcription)
Contêm dados abrangentes da conversa, incluindo transcrições completas, resultados de análise e metadados.
Campos de nível superior
Estrutura do objeto de dados
O objeto data contém:
Webhooks de áudio (post_call_audio)
Contêm dados mínimos com o áudio da conversa completa como MP3 codificado em base64.
Campos de nível superior
Estrutura do objeto de dados
O objeto data contém apenas:
Os webhooks de áudio contêm apenas os campos listados acima. Eles NÃO incluem dados de transcrição, metadados, resultados de análise ou quaisquer outros detalhes da conversa.
Webhooks de falha na iniciação de chamada (call_initiation_failure)
Contêm informações sobre tentativas de iniciação de chamadas telefônicas, incluindo motivos de falha e metadados do provedor de telefonia.
Os eventos de webhook de falha na iniciação de chamada são enviados quando uma chamada não consegue ser iniciada devido a erros de conexão, recusa do usuário em atender ou falta de atendimento. Se uma chamada cair na caixa postal ou for atendida por um serviço automatizado, nenhum webhook de falha na iniciação de chamada será enviado, pois a chamada foi iniciada com sucesso.
Campos de nível superior
Estrutura do objeto de dados
O objeto data contém:
Para chamadas de saída feitas via Twilio, failure_reason é derivado de CallStatus da Twilio: busy e no-answer são repassados como estão, e failed é informado como unknown. Outros status de chamada da Twilio não enviam um webhook de falha na iniciação de chamada.
Estrutura do objeto de metadados
A estrutura do objeto metadata varia conforme a chamada de saída tenha sido feita via Twilio ou por tronco SIP. O objeto inclui um campo type que diferencia os dois e um campo body com detalhes específicos do provedor.
Metadados SIP (type: "sip"):
O objeto body dos metadados SIP contém:
Metadados Twilio (type: "twilio"):
Exemplos de payloads de webhook
Exemplo de webhook de transcrição
Exemplo de webhook de áudio
Exemplos de webhook de falha na iniciação de chamada
Exemplo de metadados Twilio
Exemplo de metadados SIP
Entrega de webhook de áudio
Os webhooks de áudio são entregues separadamente dos webhooks de transcrição e contêm apenas os campos essenciais necessários para identificar a conversa, junto com os dados de áudio codificados em base64.
Os webhooks de áudio podem ser ativados ou desativados usando a opção “Enviar dados de áudio” nas configurações do webhook. Essa configuração pode ser definida tanto no nível do espaço de trabalho (nas configurações do ElevenAgents) quanto no nível do agente (nas substituições de webhook de agentes individuais).
Entrega por streaming
Os webhooks de áudio são entregues como solicitações HTTP em streaming com o cabeçalho transfer-encoding: chunked para processar arquivos de áudio grandes com eficiência. Cada solicitação expira após 5 minutos.
Tentativas
Quando as tentativas estão ativadas no webhook, entregas de áudio com falha são repetidas na mesma programação dos webhooks de transcrição. Uma nova tentativa reenvia o payload completo de áudio, portanto elimine duplicidades usando conversation_id. Consulte as tentativas de webhook para ver a programação, os erros que permitem nova tentativa e os limites de tamanho de áudio.
Processamento de webhooks de áudio
Como os webhooks de áudio são entregues por codificação de transferência em blocos, você precisará processar corretamente os dados em streaming:
Os webhooks de áudio podem ser arquivos grandes, então garanta que o endpoint do webhook possa processar solicitações em streaming e tenha capacidade suficiente de memória/armazenamento. O áudio é entregue no formato MP3.
Casos de uso
Acompanhamentos automatizados de chamadas
Os webhooks pós-chamada permitem criar workflows automatizados que são acionados imediatamente após o término de uma chamada. Veja algumas aplicações práticas:
Integração com CRM
Atualize seu sistema de gerenciamento de relacionamento com o cliente com dados da conversa assim que uma chamada for concluída:
Conversas com estado
Mantenha o contexto da conversa em várias interações armazenando e recuperando o estado:
- Quando uma chamada começar, envie seu ID de usuário como uma variável dinâmica.
- Quando uma chamada terminar, configure seu endpoint de webhook para armazenar os dados da conversa no banco de dados com base no ID de usuário extraído de dynamic_variables.
- Quando o usuário ligar novamente, você poderá recuperar esse contexto e enviá-lo para a nova conversa em uma variável dinâmica
{{previous_topics}}. - Isso cria uma experiência contínua em que o agente “lembra” das interações anteriores.