Handle API Rate Limits

Design Leadping clients for route-specific limits, 429 responses, Retry-After, and safe retries.

Leadping evaluates API rate limits over 60-second periods. Requests above the applicable limit return 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:

Caller context	Requests per 60 seconds
Organization	1,200
Organization API key	300
Authenticated user	300
System	1,200
IP address	120

Route-specific limits

Route-specific policies override the general caller limit:

Route category	Requests per 60 seconds
External lead intake	300
Webhooks	120
SMS sending	60
Calling	20
Authentication	20
Website contact	10
Billing	10
Number purchase	5
Exports	5

Limits are evaluated using the applicable account, credential, user, or network context. Creating additional credentials does not create independent capacity.

Handle 429 responses

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 17

{
  "status": 429,
  "title": "Too many requests.",
  "detail": "The API rate limit for this account has been exceeded."
}

Retry-After is measured in seconds.

1. Stop sending affected requests.
2. Wait for the Retry-After duration.
3. Retry only operations that are safe to repeat.
4. Add jitter when multiple workers may resume together.
5. If the header is absent, use exponential backoff with jitter.

Do not retry immediately or run competing retry loops for the same traffic. That can extend throttling and create duplicate work.

Reduce throttling

• Coordinate request budgets across workers.
• Avoid polling when a webhook or event can provide the update.
• Cache stable responses where appropriate.
• Use stable external IDs and idempotent processing for intake retries.
• Monitor sustained rate, burst rate, 429 responses, and retry volume.

Request higher throughput

Contact [e-mail] with the organization, affected routes, source keys if applicable, expected sustained and burst volume, use case, and launch date.

Higher limits require review and are not guaranteed.