One of our production conversation-flow agents stopped taking inbound calls mid-day, with no config change to the number binding at the time it broke. Sharing the isolation work because the result is strange, and I’d like to know what platform-side state could explain it.
Symptom: after a specific time, zero call objects were created on the agent — list-calls just goes quiet. Callers heard the call fail. The number’s page still showed the correct inbound agent the whole time.
What makes it interesting — the inbound webhook proves attempts were arriving: the number has an inbound webhook configured. During the outage our endpoint kept receiving webhook fires from Retell for the incoming attempts (~27 in one 7-minute window) and answered every single one with HTTP 200 in under 25 ms, returning a standard {"call_inbound":{"dynamic_variables":{...}}} body — no agent override, no denial. Despite the successful handshake, no call was ever created for any of those attempts. So the calls died between webhook-accept and call creation.
Isolation matrix, all verified:
The affected number bound to a different agent → works.
A dashboard-duplicated clone of the broken agent (we diffed clone vs original through the API — every flow node, every tool, every setting identical) bound to a number → works.
The original agent with identical content → still creates no calls.
Other numbers/agents on the same account worked normally throughout.
So: not the number, not the account, not our webhook, not the agent’s content — the failure follows the specific agent record. Identical config, different agent id, completely different behavior.
Possibly relevant: we had published new versions of the agent’s conversation flow (dashboard publish, then an API publish-agent-version) in the same general timeframe, though the last successful call predates those publishes by a couple of hours.
Questions:
What per-agent platform state exists between “inbound webhook accepted” and “call object created” that could wedge like this, while an identical clone is unaffected?
Can a version publish (dashboard or API) leave an agent’s internal published-version routing in a broken state?
Is there any self-service way to force an agent record to re-register (e.g., does publishing a fresh version reset it), or is this support-ticket-only territory?
We’ve mitigated by moving traffic to the clone, and we’ve preserved the broken agent untouched. Happy to share the agent ID, call IDs, exact timestamps, and webhook logs via DM or a support ticket — keeping them out of the public thread.
Hello @arnab Could you please share the relevant Call IDs, Agent ID, and timestamps where the issue occurred? This will help us investigate the issue more efficiently.
Hi, thanks for picking this up. The core difficulty is that the failed attempts created no call objects, so there are no call IDs for the failures themselves — that’s the bug. Here’s everything we have, all timestamps UTC, 2026-08-27:
Affected agent:agent_4a9649f27d1730e9f69086a21a (conversation-flow agent, flow conversation_flow_a60ef4bc8944, published v37) Number: +1260-----77 (purchased through Retell, Twilio provider), inbound-bound to that agent throughout — binding verified intact in the dashboard during the outage.
Last successful inbound call:call_7e84342e8ddbe4c214f2427bcc3 at 14:16. Earlier same-day successful calls for baseline: call_9823a0d11e09fc5e3d732b85823 (14:15), call_276b346c396bbc429e03cd09d2f (13:32), call_9eeea696e4c2136165ad9b09b00 (13:11). After 14:16: zero call objects ever created on this agent.
Proof attempts kept arriving: the number’s inbound webhook (https://api.metaora.ai/api/retell-functions/inbound-webhook) received fires from your platform during the outage — 19 requests in the 17:00–18:00 hour and 8 more between 18:00–18:05, every one answered HTTP 200 in under 25 ms with a standard {"call_inbound":{"dynamic_variables":{...}}} body (no override_agent_id, no denial). None of those attempts became calls. We can share our request logs if useful.
Isolation done on our side:
The same number bound to a different agent → works.
A dashboard clone of the affected agent, agent_e169b57d230e5b5f6c0e25a115 — content verified byte-identical via your API (all flow nodes, tools, settings) → works normally. The original, identical in content, still creates no calls.
Other numbers/agents on the same account received calls throughout the outage window.
Possibly relevant version activity that day: flow v36 published 16:54 (dashboard); screening agent agent_1cb1d4956c6556a51f5c26c2cb v2 and flow v37 published ~17:34 (API publish-agent-version). Note the outage began at 14:16, before all of these.
The specific asks:
Root cause on the agent record agent_4a9649f27d1730e9f69086a21a — we’ve left it completely untouched for your investigation.
Whether anything in the version-publish flow can wedge an agent’s call creation, so we can avoid retriggering it.
This was a paying law firm’s line down for several business hours — a root cause matters to us.
Thanks for the detailed isolation work — that was helpful.
The issue is not caused by your inbound webhook response. The bound agent is currently under a Trust & Safety/content review hold for impersonation, and that hold can cause inbound calls to be rejected before a Retell call object is created 345.
To move this forward, Please email the requested verification materials to support@retellai.com in one message so we can route the case to the Trust & Safety team for review.
Please include:
Company / business website URL showing the business name, description, and contact method
Business registration proof, incorporation document, EIN/tax document, business license, or similar
A short description of the use case, target audience, and how callers/leads consent to be contacted
If this agent represents or calls on behalf of another company/person, an authorization letter or signed contract showing permission to represent them
The exact opener / intro the agent uses at the start of the call
Once we have those, we’ll send the packet to the Trust & Safety team for review. I don’t want to suggest webhook or phone-number changes here because the number routing itself is still present, and changes there won’t clear the Trust & Safety hold.