Transferring Endpoint Call - Gateway Timeout

When I try to make a blind transfer of a call using the PUT request on the /2017-09-01/endpoints/{endpointId}/calls/{callId}API endpoint I’m receiving an 504 Gateway Timeout error.

The body of my request looks like below:

    "action": "blindTransfer",
    "destination": "201"

The response body looks like below:

    "name": "TimeoutError",
    "message": "Timeout error occured: Request failed to complete"

I have tried the same API to make an answer action and that works without a problem.
Is this a known issue? Am I passing the wrong value for a destination (this is an internal phone number)?

The documentation suggests that the API call should be correct, screenshot below from the docs:

The request and body look fine to me. Can you provide a time stamp for when you received this error? That will help us find the appropriate logs.

Is this an answered call? or in ringing?
If the call is in ringing can you try action redirect.

Hi Budd, Tim,

Here are the testresults:

Time      To       RedirectTo    CallFlow                Reponse
10h18     200      201           Answer then Transfer    Gateway Timeout
10h19     200      201           Transfer                Gateway Timeout
10h21     200      201           Redirect                OK
10h24     220      201           Redirect                OK
10h26     220      240           Redirect                OK (but no transfer)

Info about the numbers:

  • 200: Physical deskphone
  • 201: Physical deskphone
  • 220: Virtual phone
  • 240: CDE (Call Distribution Element)
  • All calls were made from and to an external number (so these are not internal numbers - I just left out the external numbers for privacy reasons :slight_smile: )


  • Transfer always returns a Gateway Timeout (doens’t matter if call is answered or not)
  • Redirect works as expected (and for our situation this is the way forward)
  • Redirect to a CDE doesnt work - but I think this is a platform issue

Hi Arne - Do you know your way around the 400 logs? This is the error that the 400 will commonly throw when it has a problem executing a command. If you are familiar with the logs, I’d be interested to see if this request is hitting the 400 and if so, what it says about the transfer attempt.

If you’re not familiar with the logs, you can back them up using the instructions found here (page 249) and then send me them over to me:

If it’s not even hitting the 400, then there are 3 other possible layers where the fault could be happening (which we will continue to investigate).

Hi Budd - I send you the MV400 logs via email.