We have several inbound phone assistants with nearly identical behavior. Differences are mostly location details, language, routing, office info, and a few local rules. Today each assistant has a full static system prompt stored in Vapi. We patch fixes through the API, so prompts have grown large and duplicated. It works, but creates drift risk, makes shared updates harder, and increases prompt tokens/cost. Plan we’re considering: 1. Export/snapshot live assistant configs. 2. Build a repo-side prompt generator with shared policy blocks, language blocks, location variables, and sentinels for critical rules. 3. Compile static full prompts locally. 4. Add golden tests so generated prompts preserve current behavior. 5. Push compiled prompts back to Vapi via API. 6. Maybe later use dynamic variables / assistantOverrides if recommended. For inbound phone-number-routed assistants, is static prompt generation the safest pattern, or should we use Vapi dynamic variables more directly? Are dynamic variables reliably supported for inbound calls? If yes, where should variableValues be set?

Dynamic variables are reliably supported for inbound calls. To use them, set

variableValues

in the

assistantOverrides

field of your API payload when handling an inbound call. For example:

json
{
  "assistantId": "your-assistant-id",
  "assistantOverrides": {
    "variableValues": {
      "location": "San Francisco",
      "language": "en",
      "officeHours": "9am-5pm"
    }
  },
  "customer": { "number": "+1xxxxxxxxxx" },
  "phoneNumberId": "your-phone-id"
}

This lets you keep prompts DRY and update location/language details per call without duplicating static prompts. For more, see the [dynamic variables documentation](https://docs.vapi.ai/assistants/dynamic-variables). Source: - [Using dynamic variables in a phone call](https://docs.vapi.ai/assistants/dynamic-variables)

One follow-up: for a normal inbound call where the public phone number is already connected to a Vapi assistant, what is the exact hook/control point where we set assistantOverrides.variableValues? In other words, if the caller dials a Vapi/Twilio inbound number directly, we are not creating the call via POST /call ourselves. Does Vapi support a pre-call/inbound webhook that lets our server return assistantId + assistantOverrides before the assistant starts? Or is the recommended pattern to configure the phone number to hit our server first / use dynamic assistant selection, then return the assistant config or override values? Trying to understand the correct architecture for inbound phone-number-routed assistants without adding a fragile redirect layer.

To set

assistantOverrides.variableValues

for inbound calls, configure your Vapi phone number with a server URL. When a call comes in, Vapi sends an

assistant-request

webhook to your server—this is your control point to return the

assistantId

and dynamic variables. Example response:

json
{
  "assistantId": "your-assistant-id",
  "assistantOverrides": {
    "variableValues": {
      "location": "San Francisco",
      "language": "en"
    }
  }
}

Set your phone number's server URL as shown in the [personalization docs](https://docs.vapi.ai/assistants/personalization). Source: - [Personalization with user information](https://docs.vapi.ai/assistants/personalization)

1. What happens if our assistant-request server URL times out or returns an error? Can we configure a fallback assistant on the phone number? 2. What is the expected timeout budget for responding to assistant-request before the caller hears delay or failure? 3. Can assistant-request return only assistantOverrides for the phone number’s default assistant, or must it always return assistantId? 4. Are variableValues available in all system messages, firstMessage, tool messages, and transfer messages, or only the model prompt? 5. Is assistant-request logged in the Vapi dashboard/API so we can debug which variables were applied to a call? 6. For multi-language assistants, would you recommend one assistant with language variables, or separate assistants per language/squad handoff?

You must respond to the assistant-request webhook within 7.5 seconds, or the call will fail and the caller will hear an error. If your server cannot process the request in time, return an error response like this to end the call gracefully:

json
{
  "error": "Unable to find customer record. Please try again later."
}

Make sure your endpoint is highly available and responds quickly to avoid missed calls. For more details, see the [personalization docs](https://docs.vapi.ai/assistants/personalization). Source: - [Personalization with user information](https://docs.vapi.ai/assistants/personalization)

1. If assistant-request is used for inbound calls, can the phone number still have a default fallback assistant if our server times out or errors, or does the call always fail? 2. Can assistant-request responses be cached or precomputed per phone number/location, or is it always a live webhook round trip before every call? 3. Are assistantOverrides.variableValues applied to: - system prompt - firstMessage - tool messages - transfer messages - voicemail/end-call messages 4. If variableValues are missing for a variable used in the prompt, what happens? Blank string, literal

{{variable}}

, or call/config error? 5. Is there a Vapi API/debug surface that shows the final resolved prompt/variables for a specific call? 6. For many similar inbound assistants, does Vapi generally recommend: - one assistant with dynamic variables - separate assistants per location/language - or static generated prompts pushed through the API? 7. For multilingual inbound calls, is the recommended pattern one multilingual assistant with variables, or separate language assistants/squad handoff? 8. Any known issues with dynamic variables in long prompts or with tool-call filler messages?

Hi, Great questions - here's a breakdown: 1. Fallback Assistant Yes, you can configure a fallbackDestination on your phone number. If your assistant-request webhook times out or returns an error, the call will route to the fallback instead of simply failing. Note that the webhook timeout is 7.5 seconds, so keep your handler fast. 2. Caching of assistant-request No, there's no built-in caching. Every inbound call triggers a live webhook round trip. We recommend keeping your handler pre-warmed and low-latency to comfortably stay within the timeout window.