Hi everyone, I’m trying to build a “human-first, AI-backup” inbound call flow with Vapi. Goal: when an inbound call comes in, ring a human operator first, and only if nobody answers after X seconds, automatically fall back to a normal Vapi AI assistant call (full conversational assistant — not just a scripted fallback message). I run my own server and already handle the assistant-request webhook to inject dynamic variables / choose assistants. Does Vapi support this kind of inbound behavior (human priority + AI fallback) automatically? If yes, what’s the recommended way to implement it / which hooks should be used? Thank you 🙏

To implement a "human-first, AI-backup" inbound flow, use the

assistant-request

webhook to first return a transfer destination (the human operator) with

warm-transfer-experimental

mode and a

fallbackPlan

. In your

fallbackPlan

, instead of ending the call, have your server respond by assigning the call to a full AI assistant if the human doesn't answer. Example response:

json
{
  "destination": {
    "type": "number",
    "number": "+1234567890",
    "transferPlan": {
      "mode": "warm-transfer-experimental",
      "fallbackPlan": {
        "message": "Transferring you to our AI assistant...",
        "endCallEnabled": false
      }
    }
  }
}

On fallback, your server should then handle the next

assistant-request

by assigning the AI assistant. See [Vapi call forwarding docs](https://docs.vapi.ai/call-forwarding) for details. Source: - [Call Forwarding | Vapi Documentation](https://docs.vapi.ai/call-forwarding)

We just use the carrier's built in call forwarding. For example, on Verizon (I think) you can set it to forward to another number if no one picks up the original number within a certain amount of time

Hi PG, Yes — this is fully supported. Recommended approach (concise): 1. On inbound call, return a transfer destination to the human from your assistant-request webhook using warm-transfer-experimental and a fallbackPlan with endCallEnabled: false. Example (from your message):

json
{
  "destination": {
    "type": "number",
    "number": "+1234567890",
    "transferPlan": {
      "mode": "warm-transfer-experimental",
      "fallbackPlan": {
        "message": "Transferring you to our AI assistant...",
        "endCallEnabled": false
      }
    }
  }
}

2. While Vapi dials the human, customer stays on hold (holdAudioUrl or request-complete can set music). If human answers and accepts, the transfer assistant uses

transferSuccessful

. 3. If human doesn't answer or voicemail is detected, Vapi triggers the fallback flow. Your server should respond to the subsequent assistant-request webhook by assigning/returning the full AI assistant (not just a message). Use that assistantId in the webhook response so the call resumes with the conversational assistant. Pointers and docs: - Call forwarding and transferPlan examples: https://docs.vapi.ai/call-forwarding - For assistant-managed transfers and transferAssistant tools (optional): https://docs.vapi.ai/calls/assistant-based-warm-transfer - For dynamic control patterns (if you need programmatic decisions): https://docs.vapi.ai/calls/call-dynamic-transfers Notes: - Use warm-transfer-experimental to enable fallbackPlan behavior and voicemail detection options. - Ensure your webhook logic sets the AI assistant when fallback occurs (assistant-request is the hook to change the assistant). - If using Twilio/SIP for human legs, confirm voicemail detection mode (

audio

vs

transcript

) per docs. If you want, I can provide a minimal assistant-request webhook JSON example that switches to an assistantId on fallback.

Hi Praveen, thank you for your quick answer. If I understood correctly, my server will receive 2 assistant-requests : 1. On the first one, I should respond with a destination for transfer + fallback plan (your JSON example). 2. On the second one (occurring as a fallback after transfer failed in the case no human responded), I should respond with an assistantId. My question : is there a way to differentiate those to occurrences ? Does the second one have a "is-failed-transfer-fallback" : true, or equivalent variable ? I will experiment and implement this in the coming week, thank you

Yes, you will receive two assistant-requests. The second one does not have a specific flag like "is-failed-transfer-fallback." However, you can differentiate them based on the context of the request. The first one will be to set up the transfer with the destination and fallback plan, and the second one will be the time to provide the assistantId after the fallback has been triggered. Keep an eye on the flow, and you should be able to implement your logic accordingly.