> ## 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

> 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 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.
</Warning>

## 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 [support@leadping.ai](mailto:support@leadping.ai) 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.