AiTitus :)
05/22/2026, 10:15 PMTwilio number → your own endpoint → https://api.vapi.ai/twilio/inbound_call
Twilio status → your own endpoint → https://api.vapi.ai/twilio/status
Your endpoint does three things on every inbound:
1. Forwards Twilio's payload straight through to VAPI's /twilio/inbound_call (no transformation)
2. Watches for VAPI accepting the call (websocket open or a 2xx response)
3. If VAPI didn't accept, fall back. Two options:
- Return TwiML that forwards to a phone number you've stored for that tenant (look up in a DB of clients you have by To / From, both are in Twilio's payload)
- Hand off to a different AI voice provider's inbound endpoint
Same wrapper on the status callback URL: Twilio fires status events at your endpoint, which forwards to https://api.vapi.ai/twilio/status. Bonus, you now get to log call lifecycle in your own stack as it happens.
Why this works:
- You own the routing decision, so a provider outage stops being a customer-facing event
- You can flip vendors per-tenant with a config flag, no redeploy
If you don't have infra for the middle tier, a tiny Cloudflare Worker, an n8n workflow, or a Make scenario all handle this in under 100 lines. The per-tenant fallback phone number is the easiest first step. Failover to another AI voice provider is more work but the same shape.
Ping me if you have questions and make sure to have Claude or Codex help you do this. It's more than capable of walking you through. Here's a prompt to get you started, paste it into a fresh Claude or Codex session - see in thread i attached prompt.AiTitus :)
05/22/2026, 10:16 PMAiTitus :)
05/22/2026, 10:23 PMAmanda (Vapi)
05/22/2026, 10:23 PMAiTitus :)
05/22/2026, 10:23 PMAmanda (Vapi)
05/22/2026, 10:23 PMAiTitus :)
05/22/2026, 10:24 PMAmanda (Vapi)
05/22/2026, 10:24 PMAmanda (Vapi)
05/22/2026, 10:24 PMAiTitus :)
05/22/2026, 10:24 PMAmanda (Vapi)
05/22/2026, 10:24 PMAiTitus :)
05/22/2026, 10:25 PMAiTitus :)
05/22/2026, 10:25 PMJohn George
05/23/2026, 4:05 AMAiTitus :)
05/23/2026, 10:43 AM