I am trying to use a standard tool to transfer. The setup we have is Twilio > Retell via sip trunking. Pretty standard I guess. I am trying to create a tool that is not retell's native transfer to tool but custom one. However I cannot find the call in twilio until it is over. Nor I can use twiml to transfer the call using the Twilio sid that is in the call. Not sure this is for feature request or there is already a way to do that.

Right now, when Twilio connects to Retell via SIP, Retell becomes the active call controller, so Twilio won’t expose the live call in a way you can easily manipulate with TwiML. That’s why you can’t find or redirect it until the call ends. To do a custom transfer, you’d usually need to trigger it from Retell’s side (webhook/API) and have Twilio create or redirect the call programmatically. A common workaround is mapping Retell’s call ID to Twilio’s Call SID early via webhooks. Are you trying to transfer to another agent, another SIP endpoint, or back into Twilio IVR? @derka

"trigger it from Retell’s side (webhook/API)" is there a way to trigger the transfer using API or with python SDK. "Are you trying to transfer to another agent, another SIP endpoint, or back into Twilio IVR?" just to another phone (in this case it's handled by Dialpad) here is how the transfer from retell looks like in our twilio account: CA64e3c003778cd78fa5934eecf3e8a3ef 18:57:30 EET 2026-02-11 Completed Trunking Originating +1********** +1********** sip-pstn 16 sec B @User

Great question. The main issue here is that when Retell is handling the SIP call, Twilio doesn’t fully expose that call in real time, so you only see it clearly after it’s completed. That’s why using TwiML or a direct transfer API feels blocked. The practical way around this is to trigger a handoff from Retell via webhooks, capture the Call SID early, and then use Twilio’s API (from Python) to bridge a new call to Dialpad and connect it live. Once that mapping is in place, transfers become reliable and fully controllable. If you’d like, we can go through your exact flow and set this up properly, happy to discuss it more privately and help you implement it. @derka

"The practical way around this is to trigger a handoff from Retell via webhooks" I don't get how that could be done. We get the twilio SID on call start with

telephony_identifier.twilio_call_sid

The question is how to "use Twilio’s API (from Python) to bridge a new call to Dialpad". This has to be done using Retell's internal twilio subaccount credentials (account SID and token) I guess? The call is not visible in our twilio account until the call is over... @User

That’s a really good question, and honestly this is where most teams get stuck with Retell + SIP. Even though you’re getting the twilio_call_sid, the call is still fully controlled inside Retell’s Twilio subaccount, which is why you can’t see or manage it from your own account until it ends. So yes, any real-time action (like bridging or transferring) has to be done using their subaccount credentials. The usual workaround is to use Retell’s webhook to know exactly when a transfer should happen, then from your backend (with Python), create a new outbound call to Dialpad through that subaccount and bridge it to the active call using a conference or . That’s how you basically “hand off” the call without relying on Retell’s built-in transfer. Once this is set up, you get full control. If you’d like, I’m happy to help you design this for your setup and get it working properly, we can talk it through privately and I can assist hands-on. @derka

Okay, let's try it. What do you need me to provide we use python with FastAPI and retell python sdk...

Great, that stack is perfect for this. I’ll need a few details about your Retell setup, Twilio subaccount access, and how your FastAPI handles webhooks. It’ll be easier to go over this privately so I can share a clear requirements list and map the flow properly. Feel free to DM me and we’ll get it set up. @derka

Sent you a DM @User