Hi Team, We're running into a validation issue with your /twilio/inbound_call endpoint when using a TwiML workaround recommended by Twilio support. Context: We have an active carrier escalation with Twilio for an issue where the caller's audio path isn't "woken up" at the start of the call - the caller's audio are lost. Twilio's recommended workaround is to use a short verb before connecting, which sends RTP packets to stabilize the audio path: The problem: After finishes, Twilio changes the CallStatus from ringing to in-progress. When the then hits your /twilio/inbound_call endpoint, your API rejects it with: { "message": ["CallStatus must be one of the following values: ringing"], "error": "Bad Request", "statusCode": 400 } Ask: Could the /twilio/inbound_call endpoint be updated to also accept CallStatus=in-progress? This would allow us to use Twilio's recommended workaround for the carrier audio issue while still routing calls through Vapi's inbound handler. Without this, we can't apply the silence workaround on calls handled by Vapi, and our callers continue to experience the audio loss.

The problem is likely strict validation on CallStatus=ringing. Since Twilio switches to in-progress after , the endpoint needs to accept both statuses to support their RTP wake-up workaround. I can help you update the /twilio/inbound_call handler to allow in-progress safely (without breaking existing logic), or add a small middleware layer to normalize the status before it hits validation. @Shamala

Hi, This is a known issue and we’re currently working on a fix. Workaround: You can normalize the

CallStatus

before forwarding the request to Vapi. Instead of redirecting directly to

/twilio/inbound_call

after the

<Play>

step, route the request through a small intermediary (such as a Twilio Function or proxy). The intermediary should override

CallStatus

from

in-progress

to

ringing

before forwarding the request to Vapi. Recommended approach – Twilio Function: Use a Twilio Serverless Function that receives the webhook, updates

CallStatus

to

ringing

, and then forwards the request to the Vapi endpoint. This ensures Vapi accepts the call and processes it correctly. Alternatively, if you already have a backend handling the

<Play>

+

<Redirect>

flow, you can implement a simple proxy endpoint that rewrites

CallStatus=in-progress

to

CallStatus=ringing

before forwarding the request. Best regards, Oshi Raghav Customer Support Vapi