I am writing to inquire about the behavior of outbound calls using the POST /call endpoint when the concurrency limit is exceeded. Based on a recent email announcement, I had expected that Vapi would handle the queuing of calls when the concurrency limit is reached. However, we are receiving an error (e.g., HTTP 429) for requests made on or after the scheduled release date (Nov 21) when the limit is surpassed. Could you please provide support for investigating the cause of this issue? Demand for the service built using Vapi is rapidly increasing, which has created a business-critical situation. https://cdn.discordapp.com/attachments/1445661102162706525/1445661102766555166/Action_required__queued_processing_for_POST__call_and_response_chan__-_mail.google.com_1.png?ex=6940fa51&is=693fa8d1&hm=f52838cc912d21f992bdd3ff1f5602b3ee17a220536460d3d8cb99a79535c17a& https://cdn.discordapp.com/attachments/1445661102162706525/1445661103295172671/2025-12-03_15.13.31.png?ex=6940fa52&is=693fa8d2&hm=4b57791997cd71aeb1aea047489dcb26484709474ad0a5178b7cda147578a342&

Suggestion: As a workaround for the concurrency limit, implement a queue management system using Twilio and Redis. For example, you can manually trigger processing of queued calls with the following endpoint:

js
// Manually process the call queue
app.post('/process-queue', async (req, res) => {
  try {
    await processQueue();
    res.json({ message: 'Queue processing triggered' });
  } catch (error) {
    res.status(500).json({ error: 'Failed to process queue' });
  }
});

This lets you control when queued calls are retried as capacity becomes available. See the [Vapi call queue management guide](https://docs.vapi.ai/calls/call-queue-management) for full implementation details. Source: - [Call queue management with Twilio](https://docs.vapi.ai/calls/call-queue-management)

Hi Yasu, Thanks for reaching out — happy to clarify this for you. At the moment, call queueing is only supported for outbound campaigns. Since your system is initiating individual POST /call requests, Vapi won’t automatically queue them when your concurrency limit is exceeded. In this setup, you’ll need to programmatically check how many active calls are currently running before sending a new one to avoid hitting 429 responses. We recommend attaching both the

status-update

and

end-of-call-report

webhooks to your server. By listening to these events, you can track active call counts in real time and safely manage your own queueing logic. Best regards, Kyle

Understood, thank you. So, does this mean that the release mentioned in the email has not been carried out yet? If you have a planned release schedule or roadmap, I would like to know. https://cdn.discordapp.com/attachments/1445661102162706525/1446398445488181309/Action_required__queued_processing_for_POST__call_and_response_chan__-_mail.png?ex=6945a346&is=694451c6&hm=4345fad701301ded15d4d09a5536905ee6cf3d6d091737693fa660746118b9c0&

Hi Yasu, Great question — and thanks for your patience while we verified this on our side. Based on the email you referenced, the related update has already been merged into our production repository and should be fully deployed by now. To test the new behavior, you can try initiating several outbound calls that exceed your concurrency limit. A couple of things to note during testing: - You will still receive the concurrency-limit notification email once the number of active calls reaches your configured limit — this part remains unchanged. - The key improvement from this release is that additional POST /call requests will now be queued instead of being dropped, whereas older versions would simply return a concurrency error with no queueing. If you queue up several calls above your limit, you should now see them begin executing as active calls complete rather than failing immediately. Feel free to share your test results or any logs you’d like us to review — we’re happy to help confirm everything is working as expected. Best regards, Kyle

This is really great news, but since it’s very important, I’d like to confirm one thing. As of Nov 21, we were still getting 429 errors — when was the update you mentioned actually released?

Hi, Today we tested the /post endpoint, but we are still getting the concurrency error {"timestamp": "2025-12-10T18:26:06.712895", "request_id": 59, "status_code": 400, "response_time_seconds": 0.313, "success": false, "error_message": "Over Concurrency Limit.", "response_body": {"statusCode": 400, "message": "Over Concurrency Limit.", "error": "Bad Request", "subscriptionLimits": {"concurrencyBlocked": true, "concurrencyLimit": 50, "remainingConcurrentCalls": -1}}} I am also attaching the full call logs https://cdn.discordapp.com/attachments/1445661102162706525/1448305273092575293/vapi_responses_masked.jsonl?ex=694552e5&is=69440165&hm=ea4102e52dcddcb4bec294c7676e98c883ced2857b841d3b8c3cc792713919c7&

Sorry but please let us know about this as soon as possible. This is a very critical situation for the business. If it is not supported, we will need to make changes on our side, such as switching to the camping API.

did you receive this when scheduling a call for later or attempting to start it immediately?

We never scheduled it, we attempted to start it immediately.

try scheduling it with an earliestAt value and see if you get the error.