Webhooks
Aktivera externa integrationer genom att ta emot webhook-händelser.
Översikt
Vissa händelser i ElevenLabs kan konfigureras för att utlösa webhooks, så att externa applikationer och system kan ta emot och bearbeta händelserna när de inträffar. Händelsetyper som stöds just nu är:
Konfiguration
Webhooks kan skapas, inaktiveras och tas bort från sidan med allmänna inställningar. För användare i Workspaces är det bara arbetsyteadministratörer som kan konfigurera webhooks för arbetsytan.

Efter att den har skapats kan webhooken väljas för att lyssna efter händelser i produktinställningar, till exempel Agents Platform.
Webhooks kan inaktiveras från sidan med allmänna inställningar när som helst. Webhooks som upprepade gånger misslyckas inaktiveras automatiskt om det finns 10 eller fler misslyckanden i följd och den senaste lyckade leveransen var för mer än 7 dagar sedan, eller om webhooken aldrig har levererats. Automatiskt inaktiverade webhooks måste aktiveras igen på inställningssidan. Webhooks kan tas bort om de inte används av några produkter.
Försök igen
Återförsök för webhooks kan aktiveras per webhook för att automatiskt försöka leverera igen när en begäran misslyckas. Återförsök är inaktiverade som standard. Aktivera återförsök när du skapar eller uppdaterar en webhook via API:et eller i webhook-inställningarna.
Återförsök stöds för ElevenAgents webhooks efter
samtal, inklusive händelser för transkribering
(post_call_transcription), ljud (post_call_audio) och misslyckad samtalsinitiering
(call_initiation_failure).
Schema för återförsök
När ett leveransförsök misslyckas med ett fel som kan återförsökas försöker systemet igen upp till 5 gånger med ökande fördröjning mellan försöken:
En liten slumpmässig variation (upp till 10 % av fördröjningen) läggs till vid varje återförsök för att fördela belastningen och undvika problem med många samtidiga förfrågningar.
Fel som kan återförsökas
Alla fel utlöser inte ett återförsök. Endast följande fel betraktas som möjliga att försöka igen:
5xx-statuskoder (serverfel som 500, 502, 503, 504).429(för många förfrågningar).408(tidsgränsen för begäran överskreds).- Anslutningsfel och tidsgränser för begäranden.
Begärandefel i intervallet 4xx (som 400, 401, 403, 404) försöks inte igen, eftersom de vanligtvis indikerar ett konfigurationsproblem som kräver manuell korrigering.
Kögränser per webhook
Varje webhook är begränsad till 100 väntande återförsöksjobb. Om en webhook samlar fler än 100 återförsök i kö tas ytterligare jobb bort tills befintliga återförsök har bearbetats. Detta förhindrar att en enda felkonfigurerad webhook använder för mycket resurser.
Ljudwebhooks har ytterligare två gränser. En ljudnyttolast som är större än 50 MiB levereras en gång och försöks inte igen, och återförsök för ljud i kö för en enskild webhook får totalt inte överstiga 400 MiB.
Beteende vid automatisk inaktivering
Systemet spårar på varandra följande leveransfel för varje webhook. En webhook inaktiveras automatiskt när båda följande villkor är uppfyllda:
- 10 eller fler leveransfel i följd har inträffat.
- Webhooken har aldrig levererats, eller så var den senaste lyckade leveransen för mer än 7 dagar sedan.
När en webhook inaktiveras automatiskt får arbetsyteadministratörer en e-postnotifiering. Webhooken måste aktiveras manuellt från inställningssidan innan den återupptar leveranser.
Integration
För att integrera med webhooks skapar du en slutpunktshanterare som tar emot data om webhook-händelser som POST-begäranden. Efter att signaturen har validerats bör hanteraren snabbt returnera HTTP 200 för att ange att mottagandet lyckades. Upprepade misslyckanden med att returnera ett lyckat svar kan leda till att webhooken inaktiveras automatiskt.
Nyttolasten vid återförsök är identisk med det ursprungliga leveransförsöket. Webhook-konsumenter kan inte avgöra om det är en första leverans eller ett återförsök enbart utifrån nyttolasten, så utforma din hanterare så att den är idempotent — att bearbeta samma händelse flera gånger ska ge samma resultat. Använd event_timestamp och händelsespecifika identifierare (som conversation_id) för att avdubbla händelser vid behov.
Fält på toppnivå
Exempel på webhook-nyttolast
Autentisering
Det är viktigt att mottagaren validerar alla inkommande webhooks. Webhooks har för närvarande stöd för autentisering via HMAC-signaturer. Konfigurera HMAC-autentisering genom att:
- Lagra den delade hemligheten som genereras när webhooken skapas på ett säkert sätt
- Verifiera headern ElevenLabs-Signature i din endpoint med hjälp av SDK:n
JavaScript-SDK:n exponerar constructEvent; Python-SDK:n exponerar construct_event med rawBody, sig_header och secret (dessa heter inte payload / signature i Python). Båda verifierar signaturen, validerar tidsstämpeln och tolkar JSON-payloaden.
Python
JavaScript
Exempel på webhook-hanterare med FastAPI: