Certain events within ElevenLabs can be configured to trigger webhooks, allowing external applications and systems to receive and process these events as they occur. Currently supported event types include:
Webhooks can be created, disabled and deleted from the general settings page. For users within Workspaces, only the workspace admins can configure the webhooks for the workspace.

After creation, the webhook can be selected to listen for events within product settings such as Agents Platform.
Webhooks can be disabled from the general settings page at any time. Webhooks that repeatedly fail are auto-disabled if there are 10 or more consecutive failures and the last successful delivery was more than 7 days ago or has never been successfully delivered. Auto-disabled webhooks require re-enabling from the settings page. Webhooks can be deleted if not in use by any products.
Webhook retries can be enabled per webhook to automatically reattempt delivery when a request fails. Retries are disabled by default. Enable retries when creating or updating a webhook through the API or in the webhook settings.
post_call_transcription webhooks.When a delivery attempt fails with a retryable error, the system retries up to 5 times with increasing delays between attempts:
A small random jitter (up to 10% of the delay) is added to each retry to distribute load and avoid thundering herd problems.
Not all failures trigger a retry. Only the following HTTP status codes are considered retryable:
5xx status codes (server errors such as 500, 502, 503, 504).429 (Too Many Requests).408 (Request Timeout).Request errors in the 4xx range (such as 400, 401, 403, 404) are not retried, since they typically indicate a configuration issue that requires manual correction.
Each webhook is limited to 100 pending retry jobs. If a webhook accumulates more than 100 queued retries, additional jobs are dropped until existing retries are processed. This prevents a single misconfigured webhook from consuming excessive resources.
The system tracks consecutive delivery failures for each webhook. A webhook is automatically disabled when both of the following conditions are met:
When a webhook is auto-disabled, workspace admins receive an email notification. The webhook must be manually re-enabled from the settings page before it resumes delivery.
To integrate with webhooks, create an endpoint handler to receive webhook event data as POST requests. After validating the signature, the handler should return HTTP 200 promptly to indicate successful receipt. Repeated failure to return a success response may result in the webhook becoming automatically disabled.
The retry payload is identical to the original delivery attempt. Webhook consumers cannot distinguish between an initial delivery and a retry from the payload alone, so design your handler to be idempotent — processing the same event multiple times should produce the same result. Use the event_timestamp and event-specific identifiers (such as conversation_id) to deduplicate events if needed.
It is important for the listener to validate all incoming webhooks. Webhooks currently support authentication via HMAC signatures. Set up HMAC authentication by:
The JavaScript SDK exposes constructEvent; the Python SDK exposes construct_event with rawBody, sig_header, and secret (these are not named payload / signature in Python). Both verify the signature, validate the timestamp, and parse the JSON payload.
Example webhook handler using FastAPI: