Skip to main content
Concurrency and rate limits exist to protect call quality and platform stability. They determine how many calls your account can run at the same time and how quickly your systems can trigger new calls through the API.

​
Concurrency

Concurrency is the maximum number of live calls your account can handle simultaneously. If your account is already at its concurrency limit and you trigger another call, that call may be queued or rejected depending on current platform load and how the request is being processed. For most accounts, the default concurrency limit is enough for normal day-to-day operations. If you plan to run high-volume campaigns with a large number of simultaneous calls, contact the RapidCall team to discuss expanding your limit based on your expected volume and use case.

​
How to manage concurrency

The best approach is to manage concurrency inside your workflow engine rather than relying on the platform to handle queuing for you. For example, if your account concurrency limit is 10, configure your Make.com, n8n, or custom workflow to trigger no more than 10 calls at once, then wait for some of those calls to complete before launching additional ones. This gives you more predictable behaviour and reduces the risk of hitting limits unexpectedly during live campaigns.

​
API rate limits

API rate limits control how many requests can be sent to the RapidCall API within a given period of time. These limits are separate from concurrency. Concurrency controls how many live calls can be active at once. Rate limits control how fast your systems can send API requests. If your workflow exceeds the allowed request rate, the API will return an HTTP 429 - Too Many Requests response. Your workflow should handle this gracefully by waiting briefly and retrying the request. Most workflow tools support retry logic for 429 responses.

​
Telephony considerations at scale

As call volume increases, telephony-layer issues become more important.

​
Caller ID reputation

If you place a high number of outbound calls from a single phone number, carriers may begin to flag that number as spam. This is not specific to RapidCall. It is part of how the telecom ecosystem works. A flagged number usually leads to lower answer rates, even if the agent and list quality are good. To reduce this risk:
  • use Verified Caller ID where available,
  • use Branded Caller ID for supported US numbers,
  • monitor answer rates closely,
  • and avoid pushing all volume through a single number.
A sudden drop in answer rate can be an early sign that a number has been flagged.

​
Number rotation

For high-volume outbound campaigns, it is often better to spread calls across multiple originating numbers. This reduces the call density on any single number and lowers the risk of spam detection. Your workflow can rotate numbers automatically using a simple round-robin pattern or assign different numbers to different campaign segments.

​
Country permissions

Each originating number has its own country-level calling permissions. If your campaign covers multiple countries, verify in advance that each number is allowed to place calls to the countries you need. Otherwise, calls may fail even if the rest of the workflow is configured correctly.

​
Best practice

For stable high-volume outbound operations:
  • control concurrency in your workflow,
  • handle API rate limits with retry logic,
  • spread volume across multiple numbers when needed,
  • monitor answer rates for signs of number reputation problems,
  • and confirm country permissions before launch.
That combination gives you far more control than simply pushing call volume until something breaks.