429 Too Many Requests; Leadping does not queue them.
The limit depends on both the route and the resolved caller.
General API limits
These limits apply when a route does not have a more specific policy:Route-specific limits
Route-specific policies override the general caller limit:
Limits are evaluated using the applicable account, credential, user, or network context. Creating additional credentials does not create independent capacity.
Handle 429 responses
Retry-After is measured in seconds.
- Stop sending affected requests.
- Wait for the
Retry-Afterduration. - Retry only operations that are safe to repeat.
- Add jitter when multiple workers may resume together.
- If the header is absent, use exponential backoff with jitter.
Reduce throttling
- Coordinate request budgets across workers.
- Poll only the records whose state you need, and slow polling when no state changes. Use a supported event integration when it meets the workflow’s delivery and authentication requirements.
- Cache stable responses where appropriate.
- Use stable external IDs and idempotent processing for intake retries.
- Monitor sustained rate, burst rate,
429responses, and retry volume.
Keep one retry budget
Check whether your SDK’s HTTP adapter already retries. If both the adapter and a queue worker retry the same request, a small configuration can multiply the number of attempts. Choose one layer to own retries and set a maximum attempt count and elapsed time there. For example, whenRetry-After: 17 is returned, wait at least 17 seconds before an eligible retry. Add a small randomized delay when many workers share the same traffic budget. Persist delayed work in a queue if the job must survive a process restart.
API request limits are separate from phone-number capacity, account eligibility, and carrier restrictions. A request within the API rate limit can still be blocked by one of those conditions.

