Returning destination object in server event assistant-request is not working Call ID: 019c1e4b-e4ea-7bb8-adbb-7abd8aaa4e1f Timestamp: February 2, 2026, 13:00 to 13:40 When returning this object in the server event assistant-request: { "destination": { "type": "number", "number": "+34914437550", "message": "" } } as explained here: https://docs.vapi.ai/server-url/events#transfer-only-skip-ai The call is initiated, but it only plays a voice saying "contact Vapi support." Could you help us fix this bug? Kind regards,

Suggestion: Double-check that your server responds to the

assistant-request

event within 7.5 seconds and that your JSON matches the required format. Here’s the correct response structure:

json
{
  "destination": {
    "type": "number",
    "number": "+34914437550",
    "message": ""
  }
}

If your response is delayed or the structure is incorrect, Vapi will play a fallback message. Make sure your server is fast and the response body is exactly as shown in the [Vapi documentation](https://docs.vapi.ai/server-url/events#transfer-only-skip-ai). Source: - [Vapi Server URL Events Documentation](https://docs.vapi.ai/server-url/events)

responds in less than a second, this one in 0.6 seconds

Hey, thanks for sharing the details. When Vapi plays the “contact Vapi support” message, it usually means the transfer payload isn’t being accepted at runtime, even if the structure looks right. Make sure the server event returns only the destination object (no extra fields), the number is in full E.164 format, and the response is sent synchronously without delay. Also double-check that call transfer is enabled on the assistant. Quick check: are you returning this object directly as the HTTP response, or wrapping it inside another JSON layer? @marc792

The server only returns the destination object, the number is in full E.164 format ans the response is syncronouly. Call transfer is enable in the assistant, but the assistant does not take part in it. I'm returning it directly in the http response, check the screenshots from VAPI https://cdn.discordapp.com/attachments/1468164118295875688/1468214301742465190/imatge.png?ex=6983349f&is=6981e31f&hm=3bcd0a146cb4b1547313b51dfec2ea59f16ba4352820135111bd6cd40a735309& https://cdn.discordapp.com/attachments/1468164118295875688/1468214302174609510/imatge.png?ex=6983349f&is=6981e31f&hm=8c0e2a8147dd8cf0affe72936fb0f3d01454a178dcdebf9388cfae4152e002dc&

Hey, thanks for sending the screenshots and details that really helps. From what I can see, the issue isn’t your server failing , it’s that for an Assistant Request, Vapi expects an assistant object or assistantId, not a destination object. That’s why the transfer isn’t working. We can fix this by adjusting your webhook: either return the correct assistantId if you want the assistant to handle the call first, or set up a temporary assistant that immediately forwards the call to the number. I can help you put together the exact JSON and server logic so it works smoothly. If you want, we can continue this in a private chat and I can guide you step by step or help set it up directly. @marc792

In the docs you said that is possible to sent a destination object: https://docs.vapi.ai/server-url/events#transfer-only-skip-ai When I'm returning an assistant ID and assistant object, it's working as expected; it only fails when returning a destination object. I need to send a destination object because sometimes, depending on the caller ID, I will assign the call to an assistant or to a human.

Hey Marc, Can you once test with the complete payload - { "destination": { "type": "number", "number": "+14155552671", "callerId": "{{phoneNumber.number}}", "extension": "101", "message": "Connecting you to support." }} Replace with your number, do not change callerID, and if that still does not work, send me the new call ID. I have checked the logs, and we are successfully getting a response from your webhook. Let's try with the exact structure as the docs once.

I've test it again. This is the call_id: 019c2969-05ae-7aa9-8ca1-402833171c0c This is the complete payload: { "destination": { "type": "number", "number": "+34XXXXXXXX", "callerId": "{{phoneNumber.number}}", "extension": "101", "message": "Connecting you to support." } } I've musk the number with X but it was a correct spanish number. The error is the same: Unknow error, contact vapi support

Hey Marc, please refer to my last message. Vapi free numbers can't make calls to numbers outside the US, which includes transfers too. You have to use an external number.

Is not a Vapi free number, is a twilio one: This is the id of the number: 911fd3a1-6677-4d24-b389-9ef1d880d598 https://cdn.discordapp.com/attachments/1468164118295875688/1468641991091818506/imatge.png?ex=6984c2f0&is=69837170&hm=3c10749b717342ac97d80608eb901513ee5bd90b46b456e138680439bb2385b9&

Ok, lemme check again with new call ID.

The call was already forwaded, from a spanish provider, to twillio. I've tested again directly with the twilio number, and the error is the same, this is the last call_id: 019c2d3c-804a-7bb3-9701-69cd77fc30ac

Ok, the Twilio call is better for me for debugging, as it won't involve multiple REFER. investigating it.

This is the message of the PCAP from twilio, Call is answered successfully (200 OK received) but Vapi immediately sends BYE and terminates the call. I will send the file in the email right now. BYE sip:+34XXXXXXXXX@172.18.XXX.XX:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 44.229.228.186;rport;branch=z9hG4bKZvyt0jppvKS4B Route: Max-Forwards: 70 From: ;tag=ZBmX3cS7c9cBD To: ;tag=60739226_c3356d0b_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX Call-ID: 9583c5627bc1dff5754f05cad9e5e063@0.0.0.0 CSeq: 2 BYE Content-Length: 0

We’ve investigated this, and it does appear to be a platform issue. However, it will take some additional time to identify the root cause, as we need to review session IDs, call logs, SIP logs, and related data. In the meantime, I’d recommend trying an alternative approach. One option is to call a tool at the initiation of the call that handles call transfer based on the tool’s response. You can configure an endpoint that checks the user’s number, and if it returns a positive response, the AI can inform the caller that their call is being forwarded to a human agent. Please note that you’ll need to set the speak mode to "Assistant speaks first with model generated message" for the tool to be called at the start of the call, and include the appropriate instructions in the prompt. Please consider this workaround while we work on fixing the issue. I’ve already escalated this to the engineering team.

Ok, do you know when the issue will be resolved?

No, I have escilated this issue, but it might take some more time. Will bump this internally.

Is there any place to follow up on the status of this issue?