StatusCallback reliability: expected latency, retry logic, and handling missed callbacks

overview when a call ends, exotel sends an http statuscallback to your configured statuscallback url with the final call status and related details, including the recording url when available for most calls, this callback arrives shortly after the call completes for a small percentage of calls (typically under 1%), the callback may be missing, delayed, or incomplete this article covers delivery behavior, retries, expected latency, and the recommended fallback expected latency statuscallback fires when a call reaches a final state (for example, completed, failed, busy, no answer, or canceled) under normal conditions, expect delivery within a few seconds to under a minute after the call ends in practice, delivery is typically well within 45 seconds after the callback is queued note the recording url may still be unavailable on the first callback even when the status is final it can arrive later, once the recording is ready delivery retries to your endpoint if exotel can't deliver the statuscallback to your endpoint (for example, due to a timeout, a temporary 5xx, or an http 429), it retries delivery detail value maximum delivery attempts up to 4 timeout per attempt 6 seconds retry spacing (on timeout) 30 seconds → 5 minutes → 10 minutes other temporary failures (5xx / 429) retried with a short delay (typically 30 seconds) permanent client errors (most 4xx, except 429) not retried your endpoint should respond with a 2xx (or a 3xx redirect) within 6 seconds for the delivery to count as successful when statuscallback may be missing, late, or incomplete in rare cases, complete call details aren't available in time, due to delays in the telecom/network path or in call finalization when this happens, you may see one or more of the following statuscallback isn't delivered statuscallback arrives with incomplete fields (for example, status or leg details are null/empty) the recording url is missing or arrives later than usual this is expected edge case behavior for a small fraction of calls, and doesn't usually indicate a misconfiguration on your end important the retries described above only cover delivery failures to your url (your server being down or slow) they don't cover the rarer case where exotel never queues a complete final callback because call details weren't available in time for that case, use get call details recommended fallback get call details api don't rely on statuscallback alone for 100% coverage use get call details as the source of truth whenever a callback is missing or incomplete if you don't receive a statuscallback for a callsid, call get call details for that callsid if the status or recording url is still empty or incomplete, retry with backoff — for example, start 1–2 minutes after the call, then retry every few minutes as a practical guideline, check again around 15 minutes after the call was placed or completed by then, most calls have a final status available stop retrying once you have a final status (completed, failed, busy, no answer, canceled, etc ), or once you hit a maximum retry window you define (for example, 30–60 minutes) recommended integration pattern use statuscallback for near real time updates make sure your statuscallback endpoint responds quickly (within 6 seconds) with a 2xx use get call details (with retries) to reconcile missed or incomplete callbacks optionally, run a periodic reconciliation job for callsids you initiated but never fully resolved summary topic guidance happy path latency usually seconds to under a minute after call end delivery retries up to 4 attempts, with backoff per attempt timeout 6 seconds missed/incomplete edge cases (<1%) use get call details with retries ( 15 minute practical window) recording url may lag behind final status — poll get call details if needed