How can I get customer number to show in the SIP transfer headers, or how can I deduce the customer number from the existing headers? I have tool like this { "function": { "name": "transfer_call_tool_sip" }, "messages": [ { "type": "request-start", "blocking": false } ], "async": false, "destinations": [ { "type": "sip", "sipUri": "sip:transfer@xxxxxxx.sip.twilio.com", "sipHeaders": { "X-Customer-Phone": "{{customer.number}}", "X-Lead-Id": "{{call.id}}" }, "message": "test", "description": "test", "transferPlan": { "mode": "blind-transfer", "sipVerb": "dial" } } ] } The headers from the SIP transfer show up as { "key": "SipHeader_X-Customer-Phone", "value": "{{customer.number}}" } Along with these SipHeader_X-CID Vapi Vapi internal SipHeader_X-Call-Sid Vapi Vapi internal #1 How can I get customer number to show? #2 How can I link these to Vapi CALLID if #1 is not possible?

Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team

It looks like {{customer.number}} isn’t being resolved by Vapi, so it’s being sent as a literal string in the SIP header. This usually means that variable interpolation isn’t supported in sipHeaders for transfers, or that customer.number isn’t available in the call context at that moment. In practice, the reliable way is to use SipHeader_X-Call-Sid or X-CID and map that to the customer number in your backend using Vapi webhooks or call logs before the transfer happens. You can store the relationship when the call starts, then look it up after the SIP handoff. Are you currently receiving and storing Vapi call events or webhooks for these calls? @RDOG

Thanks for the detailed response @James Christopher I looked into using Vapi webhooks however, the SipHeader_X-Call-Sid and SipHeader_X-CID are not tied to any of the information Vapi passed in it's webhooks. In other words, it does not look like any data in the webhooks allow us to deduce the SipHeader_X-Call-Sid or the SipHeader_X-CID.

I can help with that @RDOG pls let me know if u still have the issue

That’s a really solid observation, and you’re right by default, Vapi doesn’t reliably expose a direct mapping between X-Call-Sid / X-CID and webhook data, which makes correlation tricky. In practice, the safest approach is to inject your own stable identifier before the transfer using metadata or customData, then reuse that same value in the SIP headers. This gives you full control instead of relying on Vapi’s internal IDs. Another option is passing your customer or lead ID as a SIP URI parameter, which is usually preserved more consistently than custom headers. The exact solution depends on how your call flow is structured. If you’d like, we can look at your current setup privately and I can help you make it fully traceable end-to-end. @RDOG

@James Christopher I would really appreciate if we can find a short 15 min to meet and review. I still am unsure how injecting my own identifier prior to the transfer will work if vapi does not interpolate any variables.

@RDOG sent u text, lets talk

Even if Vapi doesn’t interpolate variables inside sipHeaders, you can still solve this by injecting your own identifier earlier in the flow — for example from your backend when the call starts, or by attaching it as metadata/session data. Then, when you trigger the transfer, you pass that value directly instead of relying on in-assistant templating. So the key is: you control the ID before Vapi builds the SIP request, rather than trying to generate it inside the transfer itself. A quick 15-minute review would definitely make this clearer. Send me a private message with your setup and availability, and I’ll walk you through it step by step. @RDOG