Feature Requests

Fallback Plan Bug
Mensaje a soporte de Vapi — transferencia con Zadarma BYO Org ID: 72f789ad-7f8a-4375-a874-fb495624109d Asistente: 87fd6ce2-eb9d-4e41-a140-c526334be6d0 Trunk BYO: Zadarma, credential c6debb73-76f7-404e-9c2e-6a9be846375d Número: +34864872954 --- Hola, Estamos usando transferCall con un trunk BYO SIP de Zadarma y tenemos dos problemas: 1. Pedimos activar "transfer outcome detection and fallback" para nuestra organización. Vimos en la documentación de la API que fallbackPlan en blind-transfer modes solo aplica "when transfer outcome detection and fallback are enabled for the organization". Nos gustaría activarlo: queremos que si transferimos con blind-transfer / refer y el destino no contesta, la llamada vuelva al asistente en vez de perderse en el trunk. **2. Bug reproducible en warm-transfer-experimental .** Llamada de ejemplo: 01a0d325-bdcc-7eea-96e8-4a001c24593c . El asistente-puente confirma la transferencia correctamente ( transferSuccessful a los 75.8s del log, call.transferCompleted result: connected ). Pero justo después (75.9s), antes de conectar al cliente con el destino, Vapi reactiva el asistente original y le hace decir una frase fija en inglés y rota ("Good not complete the transfer? Party mait...") que no está en nuestro prompt ni es nuestro fallbackPlan.message (que está en español). El cliente la oye ya con la llamada técnicamente unida a Jordi. call.ended con endedReason: assistant-forwarded-call llega a los 79.6s, ~4s después de esa frase. Nos pasó de forma reproducible en al menos 3 llamadas reales. ¿Es un bug conocido? ¿Se puede desactivar ese mensaje/reactivación tras un transferSuccessful ? Gracias.
0
Support Azure AI Foundry models for custom STT and TTS providers
Please extend Vapi’s Azure integration beyond LLM models so customers can use Azure AI Foundry / Azure-hosted models for the complete voice pipeline: Speech-to-text Text-to-speech LLMs Customers should be able to select an Azure AI Foundry deployment for STT or TTS even when that specific model is not yet available as a native Vapi provider. For example: An organization deploys or accesses GPT-Live-Transcribe through Azure AI Foundry, then connects that deployment to Vapi as the assistant’s realtime transcriber. Vapi would continue handling the phone call, turn-taking, tools, and orchestration, while Azure handles transcription. The integration should support: Azure AI Foundry deployment names and regional endpoints Azure authentication through managed credentials or API keys Streaming audio input for realtime STT Partial and final transcript events Streaming TTS audio output Configurable audio codecs, sample rates, and formats Language and pronunciation settings Custom model/deployment selection Regional routing and data-residency controls Clear timeout, retry, and provider-error reporting This would let customers use models that Vapi does not yet offer natively while keeping Vapi’s call handling and orchestration. It would also make Azure-hosted voice models practical for regulated deployments that require EU or Swiss-region processing. Please clarify whether this should be implemented through: A first-class Azure AI Foundry STT/TTS provider, A general custom streaming STT/TTS endpoint, Or both.
0
Eval run remains queued and never dispatches — 0b1a1ff1-7aec-43b0-a6c7-5043f03939eb
Hi Vapi Support, We are performing a controlled text-layer Eval as part of a provider integration test. The Eval run was created successfully but has remained queued and has not started execution. Eval Run ID: 0b1a1ff1-7aec-43b0-a6c7-5043f03939eb Current observations: Run state: queued Created: 2026-09-18T17:40:58.247Z Last provider update: 2026-09-18T17:40:58.430Z Falcon/custom LLM endpoint received no request No Eval results were generated No Vapi charge was incurred Account credit balance remained unchanged No second Eval has been submitted The original run has not been cancelled or modified The API reports inconsistent startedAt/endedAt timestamps while authoritative status remains queued; endedAt predates creation Our Falcon custom LLM endpoint has already been independently validated and is reachable through the deployed TEST route. We are intentionally preserving this Eval run unchanged so the original provider-side state remains available for investigation. Could you please confirm: Why this Eval run has remained queued? Whether there is an account, Eval scheduler, transient configuration, or execution prerequisite preventing it from starting. Whether you can safely resume/start this existing run without requiring us to create a replacement. If the run cannot be resumed, whether you recommend cancelling it before submitting a replacement Eval. Whether there is any additional run-level diagnostic information available for this Eval ID. We would prefer not to submit another Eval until the state of this existing run is understood. Thank you, Atif FalconAgents
0
Load More
→