Hello VAPI-Team, I have an issue with the tool/function "transferCall" - I get this Error / Ended reason (see title) when forwarding a call - from the logs it initiates the transfer but then fails (hangs up) - we are using Twilio on IE1 (previously used US). I dont get any error logs for the calls on Twilio side - it seems like VAPI is still using the US-Endpoint and can't find the number there. I saw previous posts regarding this issue but i cant see if this was ever resolved. Example Call ID: 019d00cb-8b2d-777f-a85a-d4942c573224 Thank you in advance.

To troubleshoot your transfer failure, retrieve the

phoneCallProviderId

from the Vapi call object and check the corresponding call logs in your Twilio IE1 Console. Here’s a quick example using cURL to get the call details:

bash
curl -X GET "https://api.vapi.ai/call/019d00cb-8b2d-777f-a85a-d4942c573224" \
  -H "Authorization: Bearer YOUR_API_KEY"

Look for the

phoneCallProviderId

in the response, then search for it in Twilio’s call logs to identify any transfer-related errors or region mismatches. This will help pinpoint if the issue is with Vapi’s initiation or Twilio’s handling of the transfer. For more details, see the [Vapi troubleshooting guide](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops). Source: - [Debug call forwarding drops](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops)

Thanks for the details. It looks like the transfer might be defaulting to the US endpoint, which would explain why Twilio isn’t seeing the call. I can help you pinpoint the routing issue and get transfers working correctly. Can you confirm if the number you’re forwarding to is registered on the IE1 endpoint, or should we adjust the routing configuration? @Checkker

yes it is now registered on IE1 @User

Great, that helps. Since the number is now on IE1, the next step is to verify that the transfer request is explicitly hitting the IE1 region and not falling back to US by default. In cases like this, I usually check the SIP routing + region binding at the assistant/tool level, and confirm the transfer target format (E.164 + correct edge). If you want, I can walk through your setup and trace where the mismatch is happening there’s typically a small config detail causing the fallback. @Checkker

That sounds good and would helpme a lot @Ramsey

Perfect, glad that helps. I’d start by tracing the call from Vapi to Twilio to make sure everything is actually hitting IE1, then double-check the transfer setup (number format, region, routing) to catch anything falling back to US. After that, I’ll run a quick test with logs to see exactly where it’s breaking. Happy to jump in and fix this with you, it’s usually a small config issue. Let’s take it privately so I can look at your setup and get it sorted quickly. @Checkker

ok i sent you a message @Ramsey

Hi, I just wanted to check in and see if the issue you were facing has been resolved on your end. If not, we’d be more than happy to continue investigating it from our side.

hi i solved it by switching to sip / forcing sip endpoints in IE1 for transferCall thank you for the help anyways