Retell sends multiple call_ended events within 1 sec

Retell sends multiple call_ended events within 1 sec, not honouring the webhook timeout settings. The webhook timeout settings are set to 30 sec, but duplicate events are sent within 1 sec

1 Like

Based on the webhook specification, the webhook timeout setting determines how long Retell AI waits for a success response (2xx status) from your endpoint, not the interval between retry attempts(1). The webhook has a timeout of 10 seconds by default, and if no success status is received within that timeframe, it will be retried up to 3 times(1).

The webhook timeout you configure (such as 30 seconds via webhook_timeout_ms(2)(3)) controls how long Retell AI waits for your endpoint to respond before considering the request failed and triggering a retry(1). This does not prevent multiple webhook events from being sent in quick succession if retries are triggered.

According to the documentation, webhooks are triggered in order but are not blocking(1). This means that even if a call_started webhook fails, Retell AI can still trigger the call_ended webhook(1).

There is a community report of duplicate end_call webhook events being received for the same call(4), which suggests this may be a known issue that others have experienced.

To handle potential duplicate events, you should implement idempotency in your webhook handler by tracking the call_id to ensure you only process each unique call once, even if multiple webhook events are received.

If you continue experiencing duplicate events that appear to be system-level issues rather than retry behavior, I recommend:

Hello @rakesh-convergedhub

Can you share the call id?

This is also happening to our agents

Hello @nels

Can you share a call id?

This problem has re-surfaced. Sharing the call_id with timestamp as recorded on our platform that uses Retell. The webhook timeout on Retell agent is set to 45 seconds -

Issue Summary:
For call_id: call_b2f2a5620204c036496c2a5fa7d, we received duplicate webhook events approximately 30 seconds apart:

call_ended events:

  • 2026-02-12T10:59:43.894Z UTC - First delivery
  • 2026-02-12T11:00:12.894Z UTC - Retry (~30 seconds later)

call_analyzed events:

  • 2026-02-12T10:59:46.894Z UTC - First delivery
  • 2026-02-12T11:00:16Z 11:00:16 UTC - Retry (~30 seconds later)