Webhooks pós-chamada
Receba notificações quando as chamadas terminarem e a análise estiver concluída por meio de webhooks.
Visão geral
Os webhooks pós-chamada permitem receber 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 da 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 ao iniciar chamada (
call_initiation_failure): contêm informações sobre tentativas malsucedidas de iniciar chamadas, 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 workspace 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 receptor.
Painel
CLI
SDK
Os cabeçalhos personalizados não podem ser configurados atualmente 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 para listar 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 aumentar a segurança, você pode adicionar os IPs estáticos de saída da ElevenLabs à sua lista de permissões. Consulte a lista de permissões de IP para ver a lista completa de endereços IP.
Usar uma lista de permissões de IP junto com a validação de assinatura HMAC oferece várias camadas de segurança.
Substituições de webhook por agente
Por padrão, todos os agentes do seu workspace usam o webhook configurado nas configurações do workspace. Você pode substituir essa configuração por agente para enviar dados pós-chamada a endpoints diferentes para agentes diferentes.
Painel
CLI
SDK
O post_call_webhook_id precisa fazer referência a um webhook que já exista no seu workspace. 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 da 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 completo da conversa em 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 três campos listados acima. Eles NÃO incluem dados de transcrição, metadados, resultados da análise ou quaisquer outros detalhes da conversa.
Webhooks de falha ao iniciar chamada (call_initiation_failure)
Contêm informações sobre tentativas de iniciar chamadas telefônicas, incluindo motivos da falha e metadados do provedor de telefonia.
Os eventos de webhook de falha ao iniciar chamada são enviados quando uma chamada não pode ser iniciada devido a erros de conexão, à recusa da chamada pelo usuário ou à falta de atendimento. Se uma chamada cair na caixa postal ou for atendida por um serviço automatizado, nenhum webhook de falha ao iniciar 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 pelo Twilio, failure_reason é derivado de CallStatus do Twilio: busy e no-answer são transmitidos como estão, e failed é informado como unknown. Outros status de chamadas do Twilio não enviam um webhook de falha ao iniciar chamada.
Estrutura do objeto de metadados
A estrutura do objeto metadata varia conforme a chamada de saída foi feita pelo Twilio ou por trunking SIP. O objeto inclui um campo type que diferencia os dois, além de um campo body com detalhes específicos do provedor.
Metadados SIP (type: "sip"):
O objeto body dos metadados SIP contém:
Metadados do Twilio (type: "twilio"):
Exemplos de payloads de webhook
Exemplo de webhook de transcrição
Exemplo de webhook de áudio
Exemplos de webhook de falha ao iniciar chamada
Exemplo de metadados do 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 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 workspace (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 por streaming com o cabeçalho transfer-encoding: chunked, para processar arquivos de áudio grandes de forma eficiente. Cada solicitação expira após 5 minutos.
Tentativas
Quando as tentativas estão ativadas no webhook, as entregas de áudio com falha são repetidas na mesma programação dos webhooks de transcrição. Uma nova tentativa reenvia o payload de áudio completo, portanto, elimine duplicatas 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 de streaming:
Os webhooks de áudio podem ser arquivos grandes. Portanto, garanta que seu endpoint de webhook possa processar solicitações de streaming e tenha memória/capacidade de armazenamento suficiente. 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 gestão de relacionamento com clientes com dados da conversa assim que uma chamada for concluída:
Conversas com estado
Mantenha o contexto da conversa entre várias interações armazenando e recuperando o estado:
- Quando uma chamada começar, envie o ID do usuário como 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 passá-lo para a nova conversa em uma variável dinâmica
{{previous_topics}}. - Isso cria uma experiência fluida, em que o agente “lembra” as interações anteriores.