Concurrency Management – Separating Inbound and Outbound Flows
Hi Vapi Team,
We are currently using your platform to design and operate two types of assistants: Inbound and Outbound.
Our goal is to clarify the best architectural approach to manage concurrency limits, ensuring that inbound calls are always available, even while large outbound campaigns are running.
Context
Inbound calls must be available at all times (we are using Redis to manage a queue on our side).
Outbound campaigns may involve a high volume of calls (e.g. 1,000–2,000 calls).
The main concern is that outbound campaigns can fully consume the available concurrency, making inbound lines temporarily unavailable.
Increasing the total number of concurrency lines alone does not fully solve the problem. For example, even with 1,000 concurrency lines, a sufficiently large outbound campaign could still saturate all available channels and block inbound calls.
Proposed Approach
Our current idea is to logically separate inbound and outbound traffic by using two different Vapi organizations:
Inbound Org
Dedicated to inbound assistants
Allocated with X concurrency lines
Ensures inbound availability at all times
Outbound Org
Dedicated exclusively to outbound campaigns
Allocated with Y concurrency lines
Used only for outbound execution
This way, outbound campaigns would never compromise inbound availability, as each flow would have its own isolated concurrency pool.
Questions
If we create a new organization using “Switch organization → New organization” within our existing account:
Will this new org automatically receive its own set of concurrency lines (e.g. +10)?
Or does it share the same concurrency pool as the parent organization?
If concurrency is shared, should the outbound org be created entirely outside the current organization (with a separate account / email) to guarantee isolation?
Is there any native or technical mechanism in Vapi to:
Reserve or cap concurrency for outbound campaigns (e.g. “use only X lines for outbound”)
We are currently using your platform to design and operate two types of assistants: Inbound and Outbound.
Our goal is to clarify the best architectural approach to manage concurrency limits, ensuring that inbound calls are always available, even while large outbound campaigns are running.
Context
Inbound calls must be available at all times (we are using Redis to manage a queue on our side).
Outbound campaigns may involve a high volume of calls (e.g. 1,000–2,000 calls).
The main concern is that outbound campaigns can fully consume the available concurrency, making inbound lines temporarily unavailable.
Increasing the total number of concurrency lines alone does not fully solve the problem. For example, even with 1,000 concurrency lines, a sufficiently large outbound campaign could still saturate all available channels and block inbound calls.
Proposed Approach
Our current idea is to logically separate inbound and outbound traffic by using two different Vapi organizations:
Inbound Org
Dedicated to inbound assistants
Allocated with X concurrency lines
Ensures inbound availability at all times
Outbound Org
Dedicated exclusively to outbound campaigns
Allocated with Y concurrency lines
Used only for outbound execution
This way, outbound campaigns would never compromise inbound availability, as each flow would have its own isolated concurrency pool.
Questions
If we create a new organization using “Switch organization → New organization” within our existing account:
Will this new org automatically receive its own set of concurrency lines (e.g. +10)?
Or does it share the same concurrency pool as the parent organization?
If concurrency is shared, should the outbound org be created entirely outside the current organization (with a separate account / email) to guarantee isolation?
Is there any native or technical mechanism in Vapi to:
Reserve or cap concurrency for outbound campaigns (e.g. “use only X lines for outbound”)
