Transfer Node Silently Corrupted - Settings Looked Correct But Underlying Config Was Broken

BUG


The Problem

A transfer call node in a live production agent suddenly stopped working despite no changes being made to the agent for several weeks. Transfers failed with:

“Transfer call cannot be completed, probably don’t have the permission to perform the transfer.”

The UI showed all settings as correct. I spent hours debugging Twilio - checking SIP trunks, geo permissions, subaccount settings, even creating a new trunk. Everything was fine.

The Cause

Comparing the actual JSON payloads revealed the issue:

Broken agent was sending:

{
  "type": "cold_transfer",
  "showTransfereeAsCaller": true,
  "enableBridgeAudioCue": true
}

Working agent was sending:

{
  "coldTransferMode": "sip_refer",
  "type": "cold_transfer",
  "showTransfereeAsCaller": false,
  "enableBridgeAudioCue": true
}

The coldTransferMode: "sip_refer" parameter was completely missing - even though SIP REFER was visually selected in the node configuration.

The Fix

Deleted the transfer node and recreated it with identical settings. Immediately worked.

The node’s underlying data had become corrupted while the UI continued to display the “correct” configuration.

Questions for Retell

  1. Was there a recent backend update or migration that could have caused this?

  2. Why does the UI show correct settings when the underlying config is malformed?

  3. How many other users are affected without realising?

Impact

  • Live medical clinic agent down

  • Only noticed because of a spike in callback requests from failed transfers

  • Hours of wasted debugging time chasing a Twilio issue that didn’t exist


If your transfers have suddenly stopped working and everything looks correct - try deleting and recreating your transfer node. Could save you a lot of pain.

Has anyone else experienced this?

Your bug report describes a critical issue where a transfer node’s underlying configuration became corrupted while the UI continued displaying correct settings. This is a known pattern that has affected other users.

Similar Cases

A Discord user reported a similar issue where transfer nodes in Conversation Flow Components would briefly appear, then disappear with errors, even though the configuration looked correct(1). The resolution required clearing cache and ultimately a backend fix from the Retell team(1).

Another user experienced transfer tools being created with incorrect phone numbers - the API response showed the correct number, but the dashboard displayed a different one(2). This was traced to a missing required field that Retell’s API should have rejected but didn’t(2).

Documented Transfer Requirements

For cold transfers specifically, the documentation states that when using coldTransferMode: "sip_refer", caller ID override support varies by provider(3):

  • Retell Twilio numbers support showing the user’s number on both warm and cold transfer(3)
  • Retell Telnyx numbers only support this when using SIP REFER via cold transfer(3)
  • If caller ID override is not supported, the transfer would fail(3)

Troubleshooting Steps

When call transfer fails, the documentation recommends checking(4):

  1. Verify the transfer node is properly connected to other nodes(4)
  2. Confirm the transfer destination is correctly configured(4)
  3. Check that transition conditions are correctly set up(4)
  4. Review the SIP connection log in call logs for telephony issues(4)

Reporting This Issue

Since your issue involves UI-backend data inconsistency that required node recreation to fix, and you’ve identified the specific missing parameter (coldTransferMode), I recommend:

Visit Contact Sales
Ask questions on Discord
Visit https://github.com/RetellAI/

Provide your agent ID and the specific JSON payload differences you discovered so the team can investigate whether a backend migration caused configuration corruption for other users.

Hello @Ben

There was a recent deprecation.

Please check Deprecating on 01/23/2026 - Retell AI

The fix for old agents is to switch between SIP invite and SIP refer, or as you did, to delete the node and add it again.