We just received a notice that Queued call processing is changing - i.e. "POST /call will enqueue the call for creation; the underlying transport (Twilio, Telnyx, etc.) is provisioned asynchronously i.e. not created immediately." My question is that we utilize the Call api w/ the 'phoneCallProviderBypassEnabled' parameter as recommended in this document: https://docs.vapi.ai/calls/call-handling-with-vapi-and-twilio With the upcoming changes for this Call API for outbound calls, with this have any noticeable impact on those of us using the call API with the phoneCallProviderBypassEnabled parameter to connect inbound calls?

@Vapi we share the same concerns. This is a little bit urgent since you guys just send a notice with a short time to implement the change, and there are some inconsistencies in the notice vs real scenario... we appreciate any urgency here to avoid outages!!!! Right now, when we create a call, the Twilio response includes phoneCallProvider, phoneCallTransport, phoneCallProviderBypassEnabled, and phoneCallProviderDetails with the full TwiML + callback info. We rely heavily on phoneCallProviderDetails.

phoneCallProvider: "REDACTED",
phoneCallTransport: "REDACTED",
phoneCallProviderBypassEnabled: bool,
phoneCallProviderDetails: {
    to: "REDACTED",
    from: "REDACTED",
    twiml: "<Response><Connect><Stream url='wss://{{vapi_url}}/{{callId}}/transport'><Parameter name='callId' value='{{call_id}}'/></Stream></Connect></Response>",
    statusCallback: "{{vapi_url}}/twilio/status",
    statusCallbackEvent: "REDACTED",
  },
transport: 
    provider: "REDACTED",
    accountSid: "REDACTED",
    conversationType: "REDACTED",
  },

However, the transport object does not include phoneCallProviderDetails, which makes things confusing. If transport isn’t returned consistently, can we safely assume phoneCallProviderDetails is still the correct source of truth? Your docs often don’t match the actual API responses, so we want to clarify what we should rely on. In addition to that, can't we rely on status update webhook instead of pooling? Is there any suggested timeout for this pooling?

Hi there — thanks for the great question! After reviewing the change and how

phoneCallProviderBypassEnabled

works, here’s the short answer: ✔ No impact to your inbound flow The upcoming queued call processing update does NOT affect inbound calls that use

phoneCallProviderBypassEnabled

. Why? For inbound calls, Vapi still: - Generates TwiML immediately, and - Returns it synchronously in the HTTP response (no queueing involved). That means your current flow:

Twilio → Your API → POST /call (with phoneCallProviderBypassEnabled) → Immediate TwiML → Back to Twilio → Call connects

continues to work exactly the same. **What is queued in the update?** Only: - Outbound call creation - Provisioning of transport providers - Background call lifecycle tasks Inbound bypass calls do not require provisioning, so they continue to respond instantly and won’t be sent to a queue. ---

Fantastic, thanks for the confirmation

Glad we could help!