---
title: "Inbound Vapi"
method: POST
path: "/telephony/inbound-vapi"
tags: ["Telephony"]
---

# Inbound Vapi

`POST /telephony/inbound-vapi`

Phone-call-provider-bypass inbound webhook for Vapi-routed customers
where we want full control of the Twilio CallSid.

Uses ``phoneCallProviderBypassEnabled: true`` per Vapi's
"custom call control through your telephony provider" pattern documented
at docs.vapi.ai/calls/call-handling-with-vapi-and-twilio. Vapi receives
only the audio stream and has no Twilio API access to this call, so our
later ``calls(sid).update_async`` won't race against Vapi's internal
cleanup (which would otherwise send <Hangup/> when its WebSocket closes).

Twilio's Voice webhook on the customer's number is pointed at this endpoint
instead of api.vapi.ai/twilio/inbound_call. We:
  1. Look up the customer + squad via resolve_inbound_routing.
  2. POST to Vapi /call with phoneCallProviderBypassEnabled=true so Vapi
     creates the call but does NOT touch the Twilio carrier leg.
  3. Return the <Connect><Stream> TwiML Vapi gives us back to Twilio.

Result: Vapi has no Twilio API access to the call, so calls(sid).update_async
later (during attended-transfer parking) can move the caller into a
conference without Vapi sending its <Hangup/> cleanup.

## Response `200`

Successful Response

- unknown

---

[API](https://skmtc.dev/openintake/apis/fastapi.md) · [All operations](https://skmtc.dev/openintake/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/openintake/fastapi/revisions/b642b91e0a5c/schema)