Hi — we're evaluating Vapi for an inbound flow where calls answered on our own Twilio number (our IVR answers and parks the caller in a queue) get handed to a Vapi assistant mid-call when no human agent picks up. We already run Vapi for outbound calls in production. The documented approach for our case is POST /call with phoneCallProviderBypassEnabled: true, then applying the returned phoneCallProviderDetails.twiml to the live call leg via Twilio's call-update API — per your "Call handling with Vapi and Twilio" and "Call queue management" guides. Before we build on it, we'd like clarity on its status: Support status. phoneCallProviderBypassEnabled / phoneCallProviderDetails aren't in the public OpenAPI spec (api.vapi.ai/api-json) or in any server SDK (we checked Python 1.11.1 and TS 1.2.2), though the phone-call-provider-bypass-enabled-but-no-call-received endedReason is. A staff reply in Oct 2025 said it's "only available over the API". Is this flag fully supported and committed long-term, or at risk of being retired? Any plans to add it to the spec/SDKs? Successor? The spec's CreateCallDTO.transport accepts a TwilioTransport object ({provider: 'twilio', accountSid, callSid, callToken, forwardedFrom}), and there's a TwilioTransportMessage {twiml} via send-transport-message. Is this the intended (or future-preferred) way to attach an existing in-progress Twilio call to an assistant? If so, is there a guide? For whichever mechanism you recommend: (a) does per-call context still go through assistantId + assistantOverrides.variableValues in the same POST /call, and (b) is the returned TwiML safe to apply to an already-answered call via twilioClient.calls(sid).update({twiml}) (the queue-management guide pattern), rather than as the inbound webhook response? Gating/limits. Is either path plan-gated or subject to rate/volume limits we should know about? Thank you!