I have a couple VAPI phone numbers configured like so:

json
{
  "authentication": {
    "password": "mypassword",
    "username": "myusername"
  },
  "fallback_destination": {
    "message": "Please call back later.",
    "sip_uri": "sip:fallback@mysiphost.com",
    "transfer_plan": {
      "mode": "blind-transfer",
      "sip_verb": "bye"
    },
    "type": "sip"
  },
  "name": "DEV",
  "provider": "vapi",
  "server": {
    "secret": "webhooksecret",
    "url": "https://mywebhook.com/"
  },
  "sip_uri": "sip:my-vapi-sip-uri@sip.vapi.ai",
  "status": "active",
}

It seems like no mater how I configure it if the server doesn't respond with an HTTP 2xx response code VAPI plays an error message to caller that say something like "Your server rejected get assistant request webhook, error request failed with status code 500". How can I prevent VAPI from saying this if my server is down? This seems like a bug with the fallback_destination setting on the phone number.

I understand your problem - you have configured a fallback destination for your VAPI phone number, but when your server returns a 500 error code in response to the assistant-request webhook, VAPI plays an error message to the caller saying "Your server rejected get assistant request webhook, error request failed with status code 500" instead of routing to your fallback destination. ## Why This Is Happening After reviewing VAPI's code, I can see that when your server returns a non-2xx status code (like 500), VAPI specifically categorizes this as an assistant-request-returned-error condition. In this specific error case, VAPI prioritizes playing the error message to the caller over using the fallback destination, even though you've configured a fallback destination in your phone number settings. ## Solution: Return 200 With Fallback Instructions The most effective solution is to never return a 500 error code from your webhook. Instead, even when your server encounters an internal error, you should: 1. Catch the error in your webhook handler 2. Return a 200 OK status code 3. Include a response body that explicitly directs VAPI to use your fallback destination Here's how to structure your webhook response:

javascript

// Example webhook handler in Node.js/Express

app.post('/webhook', async (req, res) => {

  try {

    // Your normal webhook processing logic

    // If an error occurs, throw it or handle it

    

    // Your normal successful response

    return res.status(200).json({

      // Your normal assistant configuration

    });

  } catch (error) {

    // When an error occurs, still return 200 but with fallback instructions

    return res.status(200).json({

      transferTo: {

        type: "sip",

        sip_uri: "sip:fallback@mysiphost.com",

        message: "Please call back later."

      }

    });

  }

});

## Why This Works Better Than Waiting for a Timeout While VAPI would eventually use your fallback destination if you don't respond at all (after the timeoutSeconds elapses), this isn't ideal because: 1. The caller experiences a long wait before being transferred 2. It consumes resources on your VAPI account waiting for the timeout 3. It creates a poor user experience By proactively returning a 200 response with fallback instructions, you: - Provide an immediate resolution for the caller - Maintain control over the call flow even during error conditions - Deliver a better caller experience ## Additional Configuration Tips Make sure your webhook is also configured to handle these other scenarios: - Network failures (using try/catch) - Authentication failures (still return 200 with fallback instructions) - Rate limiting or overload conditions (200 with fallback instructions) By implementing this solution, you'll ensure calls are properly routed to your fallback destination when your server encounters any issues, rather than having VAPI play error messages to your callers.