Hey Vapi team quick question about POST /campaign behavior. I’m creating a campaign without schedulePlan (just name, assistantId, phoneNumberId, customers), but the campaign’s calls are still being created with a schedulePlan and end up in status: scheduled instead of starting immediately. Example call shows: schedulePlan.earliestAt ≈ +2 minutes after creation and latestAt ≈ +24 hours later. Is there a way to make campaign calls start immediately (no schedule window), This is my organization id: 9d9772f3-9eb6-4d88-a410-1b90f2fd7280

Hi, from what you described, it sounds like Vapi may be automatically applying a default schedule window at the organization or campaign-processing level even when "schedulePlan" is omitted from the request. That’s likely why the calls are being created with "status: scheduled" instead of dispatching immediately. I can help investigate the campaign behavior, review the API payload/setup, and test the correct way to force immediate outbound execution without the scheduling delay. @Mango

Here is an example of the exact payload I am sending { "name": "ManyMangoes_Michigan_batch", "assistantId": "93c9c55d-6338-4fc2-af33-62a72e7ccfe3", "phoneNumberId": "99529619-e612-4a78-9d35-b1e8cc26342a", "customers": [{"number":"+17325228751"}] } I am hitting this endpoint https://api.vapi.ai/campaign Please help rectify the campaign behavior on my account so campaigns dispatch immediately instead of being automatically moved to scheduled status?

Thanks for sharing the payload this helps. From what I’m seeing, you’re not sending "schedulePlan", so Vapi is likely falling back to its default internal scheduling logic for campaigns, which is why it auto-creates a short delayed window and marks the calls as "scheduled" instead of triggering immediate execution. To make campaigns run instantly, we’ll likely need to explicitly control or override that scheduling behavior (either via an explicit “run immediately” schedule flag or by switching from campaign creation to immediate call dispatch flow depending on how Vapi has structured that endpoint). I can help you pinpoint the exact required field or alternative endpoint to force real-time execution so the calls fire immediately instead of entering the scheduler queue. Let's connect @Mango

Could you help us implement the fix to force real-time execution so calls fire immediately instead of entering the scheduler queue? We want to eliminate that default delayed window entirely. Whether that's an explicit flag in the payload or a different endpoint, we're happy to update our implementation just need the exact field or approach to use. Also want to flag two additional issues we've been hitting: 1. Concurrency counter stuck at -1 — Even with zero active, queued, or scheduled calls on the account (verified via API), the counter does not reset on its own and blocks all new calls. Your team manually reset it once but it has recurred multiple times since. Org ID: 9d9772f3-9eb6-4d88-a410-1b90f2fd7280 2. Ongoing calls not completing — Some calls connect and show as in-progress but never reach an end state. They sit open indefinitely without updating status, requiring manual intervention to unstick. Would appreciate fixes or workarounds for all three

Thanks for the detailed breakdown this actually points to a mix of API-level behavior and state management issues on Vapi’s side. For the campaign scheduling: from your payload, there’s no exposed flag that forces “immediate execution” in the "/campaign" endpoint. In practice, Vapi is still routing campaign creation through their scheduler layer, which is why it injects that short "schedulePlan" window even when it’s not provided. The reliable workaround here is usually bypassing campaigns entirely and using the direct call creation/dispatch flow (or a batch call trigger endpoint if available in your setup), which executes immediately instead of entering the campaign scheduler queue. For the concurrency stuck at "-1": that’s almost always a backend state desync rather than real usage. Since you’ve already seen a manual reset fix it once, this strongly suggests the concurrency counter isn’t being released properly when call states fail to finalize. That’s something Vapi support needs to hard reset at the account level and check for stuck “ghost sessions. For the calls stuck in in-progress: that’s typically caused by missing finalization events (hangup/webhook timeout not firing). A practical mitigation is enforcing a server-side timeout rule + explicitly triggering call termination via API when no status update is received within a threshold window, so the state can’t remain open indefinitely. If you want, I can help you restructure this into a clean implementation flow (real-time outbound + proper fail-safes + concurrency guardrails) so you don’t keep hitting these edge cases.

Okay takeover

Accept my friend request @Mango

Done

Hi, Thanks for the detailed payload and the call examples. This is actually intentional system behavior rather than a bug.

Thanks for the explanation that makes sense. Worth noting though: we are already submitting only 5 recipients per campaign, well within our 10 concurrency limit, yet we were still hitting the auto-scheduling behaviour and the counter going to -1. We suspect stuck in-progress calls are eating the slots we've observed calls that connect but never terminate or update status. Could you confirm whether stuck calls hold concurrency slots indefinitely or eventually time out on your end? Also, could you reset our concurrency counter and free all occupied slots on our account? Org ID: 9d9772f3-9eb6-4d88-a410-1b90f2fd7280 Thanks

Hi, Thanks for flagging that - you're right, stuck in-progress calls do hold concurrency slots indefinitely until they are resolved or timed out on our end. That would explain why you were hitting the auto-scheduling behavior even with only 5 recipients per campaign.

Approximately how long is a call supposed to stay in progress ? because i have a call that has been in progress for about 10 minutes every time I poll the same same status remains the same . Note that this is just a single call. "status": "in-progress", "createdAt": "2026-05-21T09:34:08.937Z", "updatedAt": "2026-05-21T09:34:09.123Z", "callsCounterEnded": 0, "callsCounterScheduled": 1, "callsCounterQueued": 1, "callsCounterInProgress": 0, "callsCounterEndedVoicemail": 0

Hi, Thanks for your patience - we've looked into the call from May 21st at 09:34 UTC. The call wasn't actually stuck in progress. It failed almost immediately due to a Twilio authentication error before any connection was established. The "status": "in-progress" you were seeing is the campaign-level status (meaning the campaign is still actively running), not the status of the individual call. You'll notice callsCounterInProgress: 0 was correct - no calls were actually connected. The root cause is a Twilio authentication failure. To fix this, please check the following: