The transfer call tool routed the call to a different extension than the one recorded in the logs. We discovered a critical bug in the Vapi transfer call tool. When multiple destinations are configured with extensions—and at least one entry uses the same base number without an extension—the system logs indicate the call is being transferred to the no-extension number. In reality, the call is routed to the first destination in the list. As a temporary workaround, we reordered the list to place the number without an extension at the top. However, this issue has already resulted in several hundred misrouted calls for our production customers. Example CallID: 019d0162-2009-7000-821e-a1319f0e4dee

Actionable Suggestion: To mitigate the misrouting issue, ensure that the destination without an extension is listed first in your

destinations

array, as the routing logic currently prioritizes the first entry when base numbers overlap. For example:

json
"destinations": [
  { "type": "number", "number": "+14155552671" },  // No extension, listed first
  { "type": "number", "number": "+14155552671", "extension": "101" }
]

Continue monitoring call logs and consider escalating to Vapi support with your findings and CallID for further investigation, as recommended in the [debug 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)

This is not documented anywhere, is this true?

I can see how serious it is, especially with live calls being misrouted. It looks like the system is prioritizing the first destination in the list rather than what the logs show, especially when mixing numbers with and without extensions. Your workaround makes sense and confirms that behavior. I can help you stabilize this by cleaning up how the destinations are structured or enforcing consistent routing before the transfer happens. Quick one, are these destinations set statically or generated dynamically (e.g. via webhook)? @alpaca

statically