Webhooki po rozmowie
Otrzymuj powiadomienia przez webhooki, gdy rozmowy się kończą i analiza jest gotowa.
Omówienie
Webhooki Webhooks po rozmowie pozwalają otrzymywać szczegółowe informacje o rozmowie po zakończeniu analizy. Po włączeniu tej opcji ElevenLabs wyśle żądanie POST na wskazany endpoint z pełnymi danymi rozmowy.
ElevenLabs obsługuje trzy rodzaje webhooków po rozmowie:
- Webhooki transkrypcji (
post_call_transcription): zawierają pełne dane rozmowy, w tym transkrypcje, wyniki analizy i metadane - Webhooki audio (
post_call_audio): zawierają minimalny zestaw danych oraz dźwięk całej rozmowy zakodowany w base64 - Webhooki nieudanego rozpoczęcia rozmowy (
call_initiation_failure): zawierają informacje o nieudanych próbach rozpoczęcia rozmowy, w tym przyczyny i metadane
Włączanie webhooków po rozmowie
Webhooki po rozmowie możesz włączyć dla wszystkich agentów w swoim obszarze roboczym na stronie ustawień ElevenAgents.

Aby webhook po rozmowie został uznany za pomyślny, musi zwrócić kod statusu 200. Webhooki, które wielokrotnie zawodzą, są automatycznie wyłączane po co najmniej 10 kolejnych błędach, jeśli ostatnie udane dostarczenie nastąpiło ponad 7 dni temu lub nie było żadnego udanego dostarczenia.
Webhooki po rozmowie mogą być automatycznie ponawiane w razie błędu. Zobacz ponawianie webhooków.
Uwierzytelnianie
Ważne, by odbiornik weryfikował wszystkie przychodzące webhooki. Webhooki obecnie obsługują uwierzytelnianie za pomocą podpisów HMAC. Aby skonfigurować uwierzytelnianie HMAC:
- Bezpiecznie przechowuj współdzielony sekret wygenerowany podczas tworzenia webhooka
- Zweryfikuj nagłówek ElevenLabs-Signature w swoim endpointzie za pomocą SDK
SDK JavaScript udostępnia constructEvent, a SDK Python construct_event z parametrami rawBody, sig_header i secret (w Pythonie nie nazywają się one payload / signature). Oba weryfikują podpis, sprawdzają znacznik czasu i parsują dane JSON.
Python
JavaScript
Przykładowy handler webhooka z użyciem FastAPI:
Niestandardowe nagłówki żądań
Oprócz weryfikacji podpisu HMAC możesz dołączać niestandardowe nagłówki do każdego dostarczenia webhooka. Przydaje się to do przekazywania kluczy API, tokenów bearer lub innych nagłówków uwierzytelniania wymaganych przez endpoint odbierający.
Panel
CLI
SDK
Niestandardowych nagłówków nie można obecnie skonfigurować w panelu ElevenAgents. Użyj SDK lub API, aby je ustawić.
Niestandardowe nagłówki działają razem z uwierzytelnianiem HMAC. auth_type nadal musi mieć wartość hmac,
a niestandardowe nagłówki są wysyłane dodatkowo obok nagłówka ElevenLabs-Signature.
Niestandardowe nagłówki są tylko do zapisu. Endpoint listy webhooków
nie zwraca w odpowiedzi request_headers, więc nie możesz odczytać nagłówków
skonfigurowanych dla webhooka.
Lista dozwolonych adresów IP
Dla większego bezpieczeństwa możesz dodać statyczne wychodzące adresy IP ElevenLabs do listy dozwolonych. Pełną listę adresów IP znajdziesz w sekcji lista dozwolonych adresów IP.
Połączenie listy dozwolonych adresów IP z weryfikacją podpisu HMAC zapewnia kilka warstw zabezpieczeń.
Zastępowanie webhooków dla poszczególnych agentów
Domyślnie wszyscy agenci w obszarze roboczym korzystają z webhooka skonfigurowanego w ustawieniach obszaru roboczego. Możesz to zastąpić dla każdego agenta osobno, aby wysyłać dane po rozmowie na różne endpointy dla różnych agentów.
Panel
CLI
SDK
post_call_webhook_id musi wskazywać webhook, który już istnieje w twoim obszarze roboczym. Możesz też określić typy zdarzeń do wysyłania za pomocą tablicy events:
Struktura odpowiedzi webhooka
ElevenLabs wysyła trzy różne typy webhooków po rozmowie, każdy o innej strukturze danych:
Webhooki transkrypcji (post_call_transcription)
Zawierają pełne dane rozmowy, w tym kompletne transkrypcje, wyniki analizy i metadane.
Pola najwyższego poziomu
Struktura obiektu danych
Obiekt data zawiera:
Webhooki audio (post_call_audio)
Zawierają minimalny zestaw danych i dźwięk całej rozmowy jako MP3 zakodowane w base64.
Pola najwyższego poziomu
Struktura obiektu danych
Obiekt data zawiera tylko:
Webhooki audio zawierają tylko trzy pola wymienione powyżej. NIE zawierają danych transkrypcji, metadanych, wyników analizy ani innych szczegółów rozmowy.
Webhooki nieudanego rozpoczęcia rozmowy (call_initiation_failure)
Zawierają informacje o próbach rozpoczęcia rozmowy telefonicznej, w tym przyczyny błędu i metadane dostawcy usług telefonicznych.
Zdarzenia webhooka nieudanego rozpoczęcia rozmowy są wysyłane, gdy nie można rozpocząć rozmowy z powodu błędów połączenia, odrzucenia rozmowy przez użytkownika lub nieodebrania jej przez użytkownika. Jeśli rozmowa trafi na pocztę głosową lub odbierze ją automatyczna usługa, webhook nieudanego rozpoczęcia rozmowy nie zostanie wysłany, ponieważ rozmowa została pomyślnie rozpoczęta.
Pola najwyższego poziomu
Struktura obiektu danych
Obiekt data zawiera:
W przypadku rozmów wychodzących przez Twilio wartość failure_reason pochodzi ze stanu Twilio CallStatus: busy i no-answer są przekazywane bez zmian, a failed jest zgłaszane jako unknown. Inne statusy rozmów Twilio nie wysyłają webhooka nieudanego rozpoczęcia rozmowy.
Struktura obiektu metadanych
Struktura obiektu metadata różni się zależnie od tego, czy rozmowa wychodząca została wykonana przez Twilio, czy przez trunking SIP. Obiekt zawiera pole type, które rozróżnia te dwa przypadki, oraz pole body ze szczegółami właściwymi dla dostawcy.
Metadane SIP (type: "sip"):
Obiekt body dla metadanych SIP zawiera:
Metadane Twilio (type: "twilio"):
Przykładowe ładunki webhooków
Przykład webhooka transkrypcji
Przykład webhooka audio
Przykłady webhooków nieudanego rozpoczęcia rozmowy
Przykład metadanych Twilio
Przykład metadanych SIP
Dostarczanie webhooków audio
Webhooki audio są dostarczane osobno od webhooków transkrypcji i zawierają tylko podstawowe pola potrzebne do identyfikacji rozmowy oraz dane audio zakodowane w base64.
Webhooki audio można włączać i wyłączać przełącznikiem „Wyślij dane audio” w ustawieniach webhooka. To ustawienie możesz skonfigurować zarówno na poziomie obszaru roboczego (w ustawieniach ElevenAgents), jak i agenta (w indywidualnych zastąpieniach webhooka agenta).
Dostarczanie strumieniowe
Webhooki audio są dostarczane jako strumieniowe żądania HTTP z nagłówkiem transfer-encoding: chunked, aby wydajnie obsługiwać duże pliki audio. Limit czasu każdego żądania wynosi 5 minut.
Ponowienia
Gdy dla webhooka włączono ponowienia, nieudane dostarczenia audio są ponawiane według tego samego harmonogramu co webhooki transkrypcji. Ponowienie wysyła cały ładunek audio, więc usuwaj duplikaty według conversation_id. Harmonogram, błędy kwalifikujące się do ponowienia i limity rozmiaru audio znajdziesz w sekcji ponawianie webhooków.
Przetwarzanie webhooków audio
Ponieważ webhooki audio są dostarczane przez kodowanie transferu chunked, musisz prawidłowo obsługiwać dane strumieniowe:
Webhooki audio mogą być dużymi plikami, dlatego upewnij się, że endpoint webhooka obsługuje żądania strumieniowe i ma wystarczającą pojemność pamięci lub przestrzeni dyskowej. Dźwięk jest dostarczany w formacie MP3.
Zastosowania
Automatyczne działania po rozmowie
Webhooki po rozmowie pozwalają tworzyć automatyczne workflow uruchamiane od razu po zakończeniu rozmowy. Oto kilka praktycznych zastosowań:
Integracja z CRM
Zaktualizuj system zarządzania relacjami z klientami danymi rozmowy zaraz po jej zakończeniu:
Rozmowy ze stanem
Utrzymuj kontekst rozmowy między wieloma interakcjami, zapisując i pobierając stan:
- Gdy rozmowa się zaczyna, przekaż identyfikator użytkownika jako zmienną dynamiczną.
- Gdy rozmowa się kończy, skonfiguruj endpoint webhooka, aby zapisywał dane rozmowy w bazie danych na podstawie identyfikatora użytkownika wyodrębnionego z dynamic_variables.
- Gdy użytkownik zadzwoni ponownie, możesz pobrać ten kontekst i przekazać go do nowej rozmowy w zmiennej dynamicznej
{{previous_topics}}. - Dzięki temu agent „pamięta” wcześniejsze interakcje, co zapewnia płynne doświadczenie.