I'd request your urgent help to this matter, our systems are scaling fast (and in Production) and Vapi APIs are responding in a very unreliable manner. Hi Team, We have a system with following properties 1. We have got 5 numbers where each number handles one call at a time. (We have limitation of one active call at a time from number provider) 2. A number is marked busy when a call request is sent to Vapi 3. A number is freed up and ready to accept calls again when we receive status ended from Vapi Webhook We still receive concurrency limits errors a lot of time. (even though we should never considering Vapi default concurrency limit is 10) For an instance, On 24 Nov 2025, at 4:43 PM - 4:44 PM (IST), there are 10 calls which are showing in Vapi call logs which were all customer busy or customer did not answer Still, all the calls between 4:44 PM - 4:48 PM failed with concurrency limits hit error. (there are no call logs between this duration in Vapi signifying that system was free during this time) It seems that Vapi doesn't free up concurrency sometimes even when there are no active calls going on. Thanks, Karun

Thank you for the detailed description. To help diagnose the concurrency issue, could you confirm if your system is consistently receiving and successfully processing the

end-of-call-report

webhook from Vapi for every call? This is crucial for accurate concurrency tracking and freeing up capacity. If possible, please check your server logs for any missed or failed webhook deliveries during the affected time window. Source: - [Call queue management with Twilio](https://docs.vapi.ai/calls/call-queue-management)

@User We rely on status-update webhooks and if the status received is ended, we mark the number free

Hi Karun, Here's some information about managing concurrency in Vapi: 1. **Default Concurrency**: Each Vapi account comes with 10 concurrent call slots. These slots represent the number of Vapi calls that can happen simultaneously. When all slots are occupied, new calls wait in a queue. 2. **Increasing Concurrency**: To handle larger volumes, you can increase your call concurrency limits. This can be done directly through the [Vapi Dashboard](https://dashboard.vapi.ai/settings/billing) by navigating to Settings → Billing and adjusting the Reserved Concurrency (Call Lines). Changes are effective immediately. 3. **Monitor Concurrency Usage**: Use the

/analytics

endpoint to track historical concurrency usage and identify patterns that might necessitate increased capacity. Here's an example request for analytics:

bash
   curl 'https://api.vapi.ai/analytics' \
   -H 'authorization: Bearer {VAPI-PRIVATE-TOKEN}' \
   -H 'content-type: application/json' \
   --data-raw '{ "queries": [{ "name": "Number of Concurrent Calls", "table": "subscription", "timeRange": { "start": "2025-10-16T18:30:00.000Z", "end": "2025-11-17T05:31:10.184Z", "step": "day" }, "operations": [{ "operation": "max", "column": "concurrency", "alias": "concurrency" }] }] }'

4. **Call Creation Response**: When creating a call (

POST /call

), the response includes

subscriptionLimits

to inform about the concurrency state, such as total slots and remaining available slots. For further details, check the documentation on [call concurrency](https://docs.vapi.ai/calls/call-concurrency).

Hi @Karun did this get resolved, we do face this issue everyday. The concurrency systems are not appropriate adn buggy in vapi since a very long time CC: @User