Webhooks
Overzicht
Je kunt bepaalde gebeurtenissen binnen ElevenLabs configureren om webhooks te activeren, zodat externe applicaties en systemen deze gebeurtenissen kunnen ontvangen en verwerken zodra ze plaatsvinden. De momenteel ondersteunde gebeurtenistypen zijn:
Configuratie
Je kunt webhooks maken, uitschakelen en verwijderen via de pagina met algemene instellingen. Voor gebruikers binnen Workspaces kunnen alleen workspacebeheerders de webhooks voor de workspace configureren.

Na het maken kun je de webhook selecteren om te luisteren naar gebeurtenissen in productinstellingen, zoals Agents Platform.
Je kunt webhooks op elk moment uitschakelen via de pagina met algemene instellingen. Webhooks die herhaaldelijk mislukken, worden automatisch uitgeschakeld als er 10 of meer opeenvolgende fouten zijn en de laatste succesvolle levering meer dan 7 dagen geleden was of nog nooit succesvol is afgeleverd. Automatisch uitgeschakelde webhooks moet je opnieuw inschakelen via de instellingenpagina. Je kunt webhooks verwijderen als ze niet door producten worden gebruikt.
Nieuwe pogingen
Je kunt per webhook nieuwe pogingen inschakelen om de aflevering automatisch opnieuw te proberen wanneer een request mislukt. Nieuwe pogingen zijn standaard uitgeschakeld. Schakel nieuwe pogingen in wanneer je een webhook maakt of bijwerkt via de API of in de webhookinstellingen.
Nieuwe pogingen worden ondersteund voor ElevenAgents-webhooks na een
gesprek, waaronder gebeurtenissen voor transcriptie
(post_call_transcription), audio (post_call_audio) en een mislukte gespreksstart
(call_initiation_failure).
Schema voor nieuwe pogingen
Wanneer een afleveringspoging mislukt met een fout waarvoor een nieuwe poging mogelijk is, probeert het systeem maximaal 5 keer opnieuw met steeds langere vertragingen tussen de pogingen:
Aan elke nieuwe poging wordt een kleine willekeurige afwijking toegevoegd (maximaal 10% van de vertraging) om de belasting te verdelen en problemen door gelijktijdige pieken te voorkomen.
Fouten waarvoor opnieuw wordt geprobeerd
Niet alle fouten leiden tot een nieuwe poging. Alleen de volgende fouten worden beschouwd als fouten waarvoor opnieuw wordt geprobeerd:
5xx-statuscodes (serverfouten zoals 500, 502, 503, 504).429(Te veel requests).408(Request-time-out).- Verbindingsfouten en request-time-outs.
Requestfouten in het 4xx-bereik (zoals 400, 401, 403, 404) worden niet opnieuw geprobeerd, omdat deze doorgaans wijzen op een configuratieprobleem dat handmatig moet worden opgelost.
Wachtrijlimieten per webhook
Elke webhook is beperkt tot 100 wachtende nieuwe pogingstaken. Als een webhook meer dan 100 nieuwe pogingen in de wachtrij verzamelt, worden aanvullende taken verwijderd totdat bestaande nieuwe pogingen zijn verwerkt. Dit voorkomt dat één verkeerd geconfigureerde webhook buitensporig veel resources verbruikt.
Audio-webhooks hebben twee extra limieten. Een audiopayload groter dan 50 MiB wordt één keer afgeleverd en niet opnieuw geprobeerd, en de nieuwe audiopogingen in de wachtrij voor één webhook mogen in totaal niet groter zijn dan 400 MiB.
Gedrag bij automatisch uitschakelen
Het systeem houdt opeenvolgende afleveringsfouten bij voor elke webhook. Een webhook wordt automatisch uitgeschakeld wanneer aan beide volgende voorwaarden is voldaan:
- Er zijn 10 of meer opeenvolgende afleveringsfouten opgetreden.
- De webhook is nog nooit succesvol afgeleverd, of de laatste succesvolle aflevering was meer dan 7 dagen geleden.
Wanneer een webhook automatisch wordt uitgeschakeld, ontvangen workspacebeheerders een e-mailmelding. De webhook moet handmatig opnieuw worden ingeschakeld via de instellingenpagina voordat deze weer afleveringen uitvoert.
Integratie
Maak voor integratie met webhooks een endpointhandler die webhookgebeurtenisgegevens als POST-requests ontvangt. Na validatie van de handtekening moet de handler snel HTTP 200 retourneren om succesvolle ontvangst aan te geven. Als je herhaaldelijk geen succesvolle respons retourneert, kan de webhook automatisch worden uitgeschakeld.
De payload bij een nieuwe poging is identiek aan de oorspronkelijke afleveringspoging. Webhookgebruikers kunnen niet alleen aan de payload zien of het om een eerste aflevering of een nieuwe poging gaat, dus ontwerp je handler idempotent — het meerdere keren verwerken van dezelfde gebeurtenis moet hetzelfde resultaat opleveren. Gebruik indien nodig event_timestamp en gebeurtenisspecifieke identificatiegegevens (zoals conversation_id) om gebeurtenissen te ontdubbelen.
Velden op het hoogste niveau
Voorbeeld van webhookpayload
Authenticatie
Het is belangrijk dat de listener alle binnenkomende webhooks valideert. Webhooks ondersteunen momenteel authenticatie via HMAC-handtekeningen. Stel HMAC-authenticatie als volgt in:
- Sla het gedeelde geheim dat is gegenereerd bij het maken van de webhook veilig op
- Verifieer de header ElevenLabs-Signature in je endpoint met de SDK
De JavaScript SDK biedt constructEvent; de Python SDK biedt construct_event met rawBody, sig_header en secret (in Python heten deze niet payload / signature). Beide verifiëren de handtekening, valideren de timestamp en parsen de JSON-payload.
Python
JavaScript
Voorbeeld van een webhookhandler met FastAPI: