Webhooks
Aktivieren Sie externe Integrationen durch den Empfang von Webhook-Ereignissen.
Übersicht
Bestimmte Ereignisse in ElevenLabs können so konfiguriert werden, dass sie Webhooks auslösen. Dadurch können externe Anwendungen und Systeme diese Ereignisse beim Auftreten empfangen und verarbeiten. Derzeit werden folgende Ereignistypen unterstützt:
Konfiguration
Webhooks können auf der Seite mit den allgemeinen Einstellungen erstellt, deaktiviert und gelöscht werden. Für Nutzer in Workspaces können nur Workspace-Administratoren die Webhooks für den Workspace konfigurieren.

Nach der Erstellung kann der Webhook ausgewählt werden, um in Produkteinstellungen wie Agents Platform auf Ereignisse zu warten.
Die Ereignisse flows_generation und flows_template_run werden beide über ein Abonnement aktiviert: Aktivieren Sie unter Select events to listen to die Option Image & Video API generation or template run completed, oder übergeben Sie das Ereignis flows an Workspace-Webhook aktualisieren. Eine Generierung oder ein Durchlauf sendet sein Ereignis nur, wenn die Erstellungsanfrage ein Feld webhook enthält.
Webhooks können jederzeit auf der Seite mit den allgemeinen Einstellungen deaktiviert werden. Webhooks, die wiederholt fehlschlagen, werden automatisch deaktiviert, wenn es 10 oder mehr aufeinanderfolgende Fehler gibt und die letzte erfolgreiche Zustellung mehr als 7 Tage zurückliegt oder nie eine erfolgreiche Zustellung erfolgte. Automatisch deaktivierte Webhooks müssen auf der Einstellungsseite wieder aktiviert werden. Webhooks können gelöscht werden, wenn sie von keinem Produkt verwendet werden.
Wiederholungen
Webhook-Wiederholungen können für jeden Webhook aktiviert werden, um die Zustellung bei fehlgeschlagenen Anfragen automatisch erneut zu versuchen. Wiederholungen sind standardmäßig deaktiviert. Aktivieren Sie Wiederholungen beim Erstellen oder Aktualisieren eines Webhooks über die API oder in den Webhook-Einstellungen.
Wiederholungen werden für ElevenAgents-Webhooks nach dem
Anruf unterstützt, einschließlich Ereignissen für Transkription
(post_call_transcription), Audio (post_call_audio) und fehlgeschlagene Anrufinitiierung
(call_initiation_failure).
Wiederholungsplan
Wenn ein Zustellversuch mit einem wiederholbaren Fehler fehlschlägt, versucht das System die Zustellung bis zu fünfmal erneut, mit zunehmenden Verzögerungen zwischen den Versuchen:
Zu jeder Wiederholung wird eine kleine zufällige Abweichung von bis zu 10 % der Verzögerung hinzugefügt, um die Last zu verteilen und Thundering-Herd-Probleme zu vermeiden.
Wiederholbare Fehler
Nicht jeder Fehler löst eine Wiederholung aus. Nur folgende Fehler gelten als wiederholbar:
- Statuscodes
5xx(Serverfehler wie 500, 502, 503, 504). 429(Too Many Requests).408(Request Timeout).- Verbindungsfehler und Anfrage-Timeouts.
Anfragefehler im Bereich 4xx (etwa 400, 401, 403, 404) werden nicht wiederholt, da sie in der Regel auf ein Konfigurationsproblem hinweisen, das manuell behoben werden muss.
Warteschlangenlimits pro Webhook
Jeder Webhook ist auf 100 ausstehende Wiederholungsjobs begrenzt. Wenn ein Webhook mehr als 100 Wiederholungen in der Warteschlange ansammelt, werden weitere Jobs verworfen, bis bestehende Wiederholungen verarbeitet wurden. Das verhindert, dass ein einzelner falsch konfigurierter Webhook übermäßig viele Ressourcen verbraucht.
Audio-Webhooks haben zwei zusätzliche Limits. Eine Audio-Nutzlast von mehr als 50 MiB wird einmal zugestellt und nicht wiederholt. Außerdem dürfen die in der Warteschlange befindlichen Audio-Wiederholungen für einen einzelnen Webhook insgesamt 400 MiB nicht überschreiten.
Verhalten bei automatischer Deaktivierung
Das System verfolgt aufeinanderfolgende Zustellfehler für jeden Webhook. Ein Webhook wird automatisch deaktiviert, wenn beide folgenden Bedingungen erfüllt sind:
- Es sind 10 oder mehr aufeinanderfolgende Zustellfehler aufgetreten.
- Der Webhook wurde nie erfolgreich zugestellt oder die letzte erfolgreiche Zustellung liegt mehr als 7 Tage zurück.
Wenn ein Webhook automatisch deaktiviert wird, erhalten Workspace-Administratoren eine E-Mail-Benachrichtigung. Der Webhook muss auf der Einstellungsseite manuell wieder aktiviert werden, bevor er Zustellungen fortsetzt.
Integration
Um Webhooks zu integrieren, erstellen Sie einen Endpoint-Handler, der Webhook-Ereignisdaten als POST-Anfragen empfängt. Nach der Validierung der Signatur sollte der Handler umgehend HTTP 200 zurückgeben, um den erfolgreichen Empfang zu bestätigen. Wenn wiederholt keine erfolgreiche Antwort zurückgegeben wird, kann der Webhook automatisch deaktiviert werden.
Die Nutzlast bei einer Wiederholung ist identisch mit dem ursprünglichen Zustellversuch. Webhook-Empfänger können anhand der Nutzlast allein nicht zwischen einer ersten Zustellung und einer Wiederholung unterscheiden. Gestalten Sie Ihren Handler daher idempotent – die mehrfache Verarbeitung desselben Ereignisses sollte dasselbe Ergebnis erzeugen. Verwenden Sie bei Bedarf event_timestamp und ereignisspezifische Kennungen wie conversation_id, um Ereignisse zu deduplizieren.
Felder der obersten Ebene
Beispiel für eine Webhook-Nutzlast
Authentifizierung
Der Listener muss alle eingehenden Webhooks validieren. Webhooks unterstützen derzeit die Authentifizierung über HMAC-Signaturen. So richten Sie die HMAC-Authentifizierung ein:
- Speichern Sie das beim Erstellen des Webhooks generierte gemeinsame Geheimnis sicher.
- Verifizieren Sie den Header ElevenLabs-Signature in Ihrem Endpunkt mithilfe des SDK.
Das JavaScript-SDK stellt constructEvent bereit, das Python-SDK construct_event mit rawBody, sig_header und secret (diese heißen in Python nicht payload / signature). Beide verifizieren die Signatur, validieren den Zeitstempel und parsen die JSON-Nutzlast.
Python
JavaScript
Beispiel für einen Webhook-Handler mit FastAPI: