Webhooki
Włącz integracje zewnętrzne, odbierając zdarzenia webhook.
Omówienie
Wybrane zdarzenia w ElevenLabs można skonfigurować tak, aby wywoływały webhooki, dzięki czemu zewnętrzne aplikacje i systemy mogą je odbierać i przetwarzać na bieżąco. Obecnie obsługiwane są następujące typy zdarzeń:
Konfiguracja
Webhooki można tworzyć, wyłączać i usuwać na stronie ustawień ogólnych. W przypadku użytkowników w obszarach roboczych webhooki dla obszaru roboczego mogą konfigurować tylko jego administratorzy.

Po utworzeniu webhook można wybrać do nasłuchiwania zdarzeń w ustawieniach produktu, na przykład Agents Platform.
Zdarzenia flows_generation i flows_template_run są włączane przez jedną subskrypcję: w sekcji Select events to listen to zaznacz Image & Video API generation or template run completed albo przekaż zdarzenie flows do Update workspace webhook. Generowanie lub proces wysyła swoje zdarzenie tylko wtedy, gdy żądanie jego utworzenia zawiera pole webhook.
Webhooki można w każdej chwili wyłączyć na stronie ustawień ogólnych. Webhooki, które wielokrotnie zawodzą, są automatycznie wyłączane, jeśli wystąpiło co najmniej 10 kolejnych niepowodzeń, a ostatnie udane dostarczenie miało miejsce ponad 7 dni temu lub nie było żadnego udanego dostarczenia. Webhooki wyłączone automatycznie trzeba ponownie włączyć na stronie ustawień. Webhooki można usunąć, jeśli nie są używane przez żadne produkty.
Ponowienia
Ponowienia webhooków można włączyć osobno dla każdego webhooka, aby automatycznie ponawiać dostarczenie, gdy żądanie się nie powiedzie. Ponowienia są domyślnie wyłączone. Włącz je podczas tworzenia lub aktualizowania webhooka przez API albo w ustawieniach webhooka.
Ponowienia są obsługiwane dla webhooków po połączeniu
ElevenAgents, w tym zdarzeń transkrypcji
(post_call_transcription), audio (post_call_audio) i niepowodzenia rozpoczęcia połączenia
(call_initiation_failure).
Harmonogram ponowień
Gdy próba dostarczenia zakończy się błędem kwalifikującym się do ponowienia, system podejmuje do 5 prób z rosnącymi opóźnieniami:
Do każdego ponowienia dodawane jest niewielkie losowe odchylenie (do 10% opóźnienia), aby rozłożyć obciążenie i uniknąć problemów typu thundering herd.
Błędy kwalifikujące się do ponowienia
Nie wszystkie błędy wywołują ponowienie. Za kwalifikujące się uznawane są tylko:
- Kody stanu
5xx(błędy serwera, takie jak 500, 502, 503, 504). 429(Too Many Requests).408(Request Timeout).- Błędy połączenia i przekroczenia limitu czasu żądania.
Błędy żądań z zakresu 4xx (takie jak 400, 401, 403, 404) nie są ponawiane, ponieważ zwykle wskazują problem z konfiguracją wymagający ręcznej poprawy.
Limity kolejki dla webhooka
Każdy webhook może mieć maksymalnie 100 oczekujących zadań ponowienia. Jeśli webhook zgromadzi ponad 100 ponowień w kolejce, dodatkowe zadania są odrzucane, dopóki istniejące ponowienia nie zostaną przetworzone. Zapobiega to zużywaniu nadmiernych zasobów przez jeden błędnie skonfigurowany webhook.
Webhooki audio mają dwa dodatkowe limity. Ładunek audio większy niż 50 MiB jest dostarczany raz i nie jest ponawiany, a oczekujące ponowienia audio dla jednego webhooka nie mogą łącznie przekraczać 400 MiB.
Automatyczne wyłączanie
System śledzi kolejne niepowodzenia dostarczania dla każdego webhooka. Webhook jest automatycznie wyłączany, gdy spełnione są oba poniższe warunki:
- Wystąpiło co najmniej 10 kolejnych niepowodzeń dostarczania.
- Webhook nigdy nie został pomyślnie dostarczony lub ostatnie udane dostarczenie miało miejsce ponad 7 dni temu.
Gdy webhook zostanie automatycznie wyłączony, administratorzy obszaru roboczego otrzymują powiadomienie e-mail. Webhook trzeba ręcznie włączyć ponownie na stronie ustawień, zanim wznowi dostarczanie.
Integracja
Aby zintegrować webhooki, utwórz procedurę obsługi punktu końcowego, która odbiera dane zdarzeń webhook jako żądania POST. Po zweryfikowaniu podpisu procedura powinna szybko zwrócić HTTP 200, aby potwierdzić pomyślny odbiór. Powtarzający się brak odpowiedzi sukcesu może spowodować automatyczne wyłączenie webhooka.
Ładunek ponowienia jest identyczny jak przy pierwotnej próbie dostarczenia. Odbiorcy webhooków nie mogą rozróżnić pierwszego dostarczenia od ponowienia wyłącznie na podstawie ładunku, dlatego zaprojektuj procedurę jako idempotentną — wielokrotne przetworzenie tego samego zdarzenia powinno dawać ten sam wynik. W razie potrzeby użyj event_timestamp i identyfikatorów charakterystycznych dla zdarzenia (takich jak conversation_id) do usuwania duplikatów.
Pola najwyższego poziomu
Przykładowy ładunek webhooka
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: