the other tansfer tools correctly use callerId, and you can even use {{customer.number}} warm transfer does not work even if there is a valid phone number hard coded in "destination": { "type": "number", "number": "+15555665831", "callerId": "+15559004852", "transferPlan": { "mode": "warm-transfer-experimental", "message": "", "sipVerb": "refer",

Currently, the documentation does not confirm that

callerId

is supported in

warm-transfer-experimental

mode. While other transfer modes allow setting

callerId

, this property may be ignored in the experimental warm transfer. Suggestion: Try using a standard warm transfer mode (such as

warm-transfer-with-message

) if you require custom

callerId

support, as shown below:

json
"transferPlan": {
  "mode": "warm-transfer-with-message",
  "message": "Transferring your call now."
}

If you must use

warm-transfer-experimental

, consider reaching out to Vapi support for clarification or a possible workaround, as this may be a current platform limitation. Source: - [Call Forwarding Documentation](https://docs.vapi.ai/call-forwarding)

@Vapi Support Bot this is vapi support, should i send an email?

Since the documentation does not confirm

callerId

support in

warm-transfer-experimental

mode, and this appears to be a platform limitation, the best next step is to email Vapi engineering or product leads for official clarification or to request a feature update. Action: Send a brief email describing the issue, including your configuration and the observed behavior, so it can be reviewed and tracked by the appropriate team. For reference, see the [Call Forwarding Documentation](https://docs.vapi.ai/call-forwarding). Source: - [Call Forwarding Documentation](https://docs.vapi.ai/call-forwarding)

Hey Ham, The caller ID is not currently available in warm transfer mode; it works in other modes, but warm transfer requires the call to be initiated from a Twilio number. That's why it's not possible as of now, but our team is looking for possible workarounds.

thanks for the reply, I hope you find a solution. We are trying to track the second leg of the call and the second leg is all coming from the same number (user number), there is no call sid or anything reported to attach the initial call to the transferred call so its a bit of a headache to track.