In the logs it perfectly is showing where it is supposed to transfer but the actual transfer is only going to one place, i need help on this @Vapi Callid: 019d2bb9-981c-7ddc-af84-d9ea20ea8c28

Thank you for sharing the details and call ID. To help troubleshoot, could you confirm whether your

transferCall

configuration includes multiple destinations in the

destinations

array, or are you using dynamic routing via a webhook/server? This will help identify if the issue is with configuration or routing logic. Sources: - [Assistant-based warm transfer documentation](https://docs.vapi.ai/calls/assistant-based-warm-transfer) - [Debug forwarding drops](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops) - [Dynamic call transfers](https://docs.vapi.ai/calls/call-dynamic-transfers)

Looks like the logic is right in logs, but the actual transfer is falling back to one destination. Usually this happens when a default number or provider-level override kicks in. I’d double-check how the transfer target is being passed at execution, not just in logs. Are you routing via Twilio/SIP, and is there any fallback set there? @nightcrawler

@Matt am routing with twilio, does this usually happen

Got it, if there’s no fallback set in your tool or VAPI, then this is probably happening at the execution layer, not your logic. I’d take a closer look at the actual transfer payload at call time vs what the logs show, just to confirm the right destination is really being sent through. It could also be the provider silently defaulting or reusing a previous destination. Happy to jump in with you and help figure it out. @nightcrawler

Hi there, Thanks for sharing the call ID — I took a look on our end. To help us narrow this down, could you clarify what you expected to happen vs. what actually happened during the transfer? From what we’re seeing, multiple destinations are configured on the tool, but it looks like the transfer may have used the text argument instead of a phone number at execution time. Could you also provide a bit more detail on: • How your

transferCall

tool is structured (especially the destinations array / arguments) • How routing is configured on the Twilio side (any fallback numbers, Studio flows, or overrides) This will help us determine whether this is a configuration issue or something happening at execution time. Looking forward to your reply. Best, VAPI Support