All of my call transfers are stopped working when initiated by the agent, the tool appears successful but no action happened when it triggers. Tried with the forwardingPhoneNumber setting and making a new transfer tool and using it. Both do the same thing. Transfer Call tool properly is configured and did transfers before (Blind Transfer, destination +447758314202). On call ID 019e5124-e55b-7000-8ce6-4e5dd1c080d3, the tool fires correctly — tool_call_result returns 'Transfer initiated.' — but no actual telephony transfer happens. Call ends with assistant-forwarded-call reason. Twilio shows no outbound dial attempt and no error during this call's timestamp. Same pattern on other sub-accounts. Transfers worked across multiple accounts 2 weeks ago. This appears to be a regression in Vapi's transfer-execution path between tool invocation and the underlying telephony provider. Organization ID: 7c0cb69e-9ca7-4d1b-8189-7c4ec84c3eba https://cdn.discordapp.com/attachments/1507469993028358386/1507469993388933201/image.png?ex=6a120455&is=6a10b2d5&hm=1c4c3c17f23c4d849c0faaf4534051aea29a5e09b5966e7f3f092468e4cb611d&

This looks more like a Vapi transfer-execution regression since the tool returns success but Twilio never receives the outbound dial request. Since it’s affecting multiple sub-accounts and worked before, the issue is likely happening between tool execution and provider handoff. I can help trace the exact failure point and validate the transfer flow end-to-end. Have you tested this with a different telephony provider setup or only Twilio so far? @Jan

Only twillio

Got it. Then the next thing I’d check is whether Vapi is actually passing the transfer request to Twilio or failing before the handoff happens. I’d also compare the failed calls with older working ones in Twilio logs to see what changed. The fact that Twilio never sees the outbound dial attempt is the main clue here. If you want an extra hand troubleshooting it, happy to discuss it privately and help dig deeper. @Jan

Twilio's not seeing it. On the failing call (019e5124-e55b-7000-8ce6-4e5dd1c080d3, ~19:23 UTC), Twilio shows no child call leg associated with the parent inbound and no errors in the Monitor → Logs → Errors view for that timestamp. So either Vapi isn't reaching the Twilio API at all, or it's failing before the request is sent. Either way it's upstream of the provider What's the next step? Yes we can discuss it privately.

That actually makes perfect sense now. With "phone-call-control" enabled, Vapi assumes your server is taking over call orchestration, so if those handlers aren’t implemented the transfer flow just dies silently before Twilio ever gets the API request. Good catch isolating it from the provider layer instead of chasing Twilio configs. What I usually recommend is keeping AI/composer changes isolated from production assistants and diff-checking every config update before deploying, especially around serverMessages, tools, URLs, and transfer/handoff settings. A lot of these issues come from silent config mutations rather than actual telephony failures. You handled the debugging the right way thoug, following the call path step by step from tool execution → provider handoff → Twilio logs is exactly the methodology I’d use. @Jan