> ## Documentation Index
> Fetch the complete documentation index at: https://leadping.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Handle API Rate Limits

> Build Leadping API clients that respect route-specific rate limits, handle 429 responses and Retry-After headers, and retry requests safely under load.

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 |
| 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 theme={null}
HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 17
```

```json theme={null}
{
  "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.

> [!WARNING]
>
> 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.
* 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, `429` responses, 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, when `Retry-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.

| Operation | Retry consideration |
| - | - |
| Read a lead or request a list page | Retry transient failures within a bounded budget |
| Create a lead | Reconcile a timeout or ambiguous failure before resubmitting |
| Send an SMS, start a call, or purchase a number | A repeated request may repeat a billable action; inspect its result before retrying |
| A receiver returns `429` to an automation webhook | This page’s client policy does not describe the automation action’s retry scheduling; see [Automation Webhooks](https://leadping.ai/docs/validating-webhooks.md) |

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.

## Request higher throughput

Contact [support@leadping.ai](mailto:support@leadping.ai) with the organization, affected routes, source names or IDs if applicable (never source keys), expected sustained and burst volume, use case, and launch date.

Higher limits require review and are not guaranteed.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.