Hi, I’m looking for clarification on error handling behavior when initiating a call to VAPI. We’re seeing cases where, if something goes wrong on VAPI’s side, VAPI answers the call and plays a system error message to the caller instead of routing the call to our configured fallback destination. VAPI SIP Phone Number ID: '8292d550-83e0-4d69-a185-2efb91e48253' For example: * During the recent channel concurrency issue (where VAPI incorrectly assumed we had exceeded our concurrency limit), callers heard: “Channel concurrency limit reached.” * When the wallet briefly showed a negative balance (this occurred while we were troubleshooting the concurrency issue and adjusting settings), callers heard: “Your wallet has a negative balance.” In both scenarios, we expected the call to route to our fallback destination rather than have VAPI answer and play a system-generated message to our customers. Can you clarify: 1. Why the fallback destination is not being respected in these scenarios? 2. Whether this behavior is expected? 3. If there is a way to configure VAPI so that system-level errors (concurrency limits, billing state, etc.) result in the call being sent to the fallback destination instead of answering and playing an error message? We’d strongly prefer that end users never hear internal system or billing messages directly. Thanks.

Thank you for the detailed explanation. Based on the documentation, it is possible to configure assistant hooks to transfer calls to a fallback destination when certain errors (like "pipeline-error") occur, but it is unclear if system-level errors such as concurrency or billing issues are always handled this way. Could you confirm if you currently have any assistant hooks configured for error handling (e.g., for "pipeline-error" events), or is your fallback destination set only at the phone number/session level? This will help determine if additional configuration is needed to achieve your desired behavior. If you can share your current configuration, I can provide more targeted guidance. Sources: - [Vapi Assistant Hooks Documentation](https://docs.vapi.ai/assistants/assistant-hooks) - [Vapi Sessions API Reference](https://docs.vapi.ai/api-reference/sessions/create) - [Vapi Phone Numbers API Reference](https://docs.vapi.ai/api-reference/phone-numbers)

I have the following hooks configured on the phone number:

json
[{'do': {'destination': {'sipUri': 'sip:fallback@my-sip-server.com', 'transferPlan': {'mode': 'blind-transfer', 'sipVerb': 'bye'}, 'type': 'sip'}, 'type': 'transfer'}, 'filters': [{'key': 'call.endedReason', 'oneOf': ['assistant-request-failed', 'assistant-request-returned-error', 'assistant-request-returned-unspeakable-error', 'assistant-request-returned-invalid-assistant', 'assistant-request-returned-no-assistant'], 'type': 'oneOf'}], 'on': 'call.ending'}]

Please share your call id, where you are seeing this issue.

No call is created for these calls but it happens 100% of the time for every user of VAPI. Also the API not allowing us to set pipeline-error for the hooks? I can't provide a call id because its not relevant.

Please share your Org Id, I will look into it further

Org ID: 7e4f30a5-9dad-4520-ab4b-2fea9222ca27 I have hooks configured on the SIP phone number with ID: 8292d550-83e0-4d69-a185-2efb91e48253. All of my calls are routed through this SIP phone number. Thank you very much for looking into this.

Hi, Fallback only works after the call has successfully started and an error occurs during the call. In that case, the fallback mechanism can trigger. However, in your setup the call never actually started, which means no hooks or fallback logic would be triggered.

@Oshi Raghav Is there currently any way to prevent VAPI from answering a call and playing system-generated messages directly to our customers? For example, during the concurrency issue (where calls were incorrectly counted), VAPI answered calls and played a message about concurrency limits. From a business standpoint, this is really unprofessional.... end users should not hear internal system or billing-related messages. In these cases, the call should be rejected, not answered. For example respond with different SIP response codes for different errors: - 503 Service Unavailable for concurrency/capacity issues - 403 Forbidden (or 402 Payment Required) for billing/account state issues - 500/503 for internal platform errors This is pretty much standard in the telco world.

Hi, This behavior is expected. To avoid such issues, we kindly recommend ensuring that sufficient credits are available in your wallet before initiating calls. At the moment, this behavior cannot be changed. Additionally, if errors such as 503, 403, or 500 occur, the calls will be rejected