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

# Rate limits & throttling

> How TIC protects the API from abuse. Both LENS (v2) and the legacy v1 API use per-IP and per-API-key sliding-window rate limits, with 429 responses when exceeded.

<Info>
  This page is the shared overview for both APIs. For **LENS (v2)** specifics — exact windows, every response header, and the full error reference — see [Rate limits in the v2 API](/api-lens/rate-limits).
</Info>

TIC rate-limits every request to protect the service from abuse and keep response times fast for everyone. When you hit a limit, the API responds with **HTTP 429** and tells you exactly when you can retry via the `Retry-After` header.

## How limits are enforced

Both APIs enforce rate limits at two levels, using sliding windows:

| Level              | Purpose                                                                                               |
| ------------------ | ----------------------------------------------------------------------------------------------------- |
| **Per IP address** | Applied to every request regardless of authentication. Protects the platform from anonymous flooding. |
| **Per API key**    | Applied on top of IP limits for authenticated requests. Your plan determines the quotas.              |

Defaults are below. Actual quotas depend on your plan.

| Level                       | Per minute | Per day | Per month | Unique IPs (per key) |
| --------------------------- | ---------- | ------- | --------- | -------------------- |
| **Per IP** (both APIs)      | 600        | 15,000  | —         | —                    |
| **Per API key** (both APIs) | 60         | —       | 3,000     | 20                   |

For LENS (v2) specifics including all response headers and error messages, see **[Rate limits in the v2 API Reference](/api-lens/rate-limits)**.

## Response headers

Every response includes rate-limit headers so you can track your usage and throttle proactively.

| Header                         | Meaning                                        |
| ------------------------------ | ---------------------------------------------- |
| `X-RateLimit-Limit`            | Quota for the current period                   |
| `X-RateLimit-Remaining`        | Requests remaining in the period               |
| `X-RateLimit-Reset`            | Seconds until the period resets                |
| `X-RateLimit-Limit-Minute`     | Per-minute quota                               |
| `X-RateLimit-Remaining-Minute` | Requests remaining in the current minute       |
| `X-RateLimit-Limit-IP`         | Maximum unique source IPs allowed for the key  |
| `X-RateLimit-Remaining-IP`     | Unique IPs remaining                           |
| `Retry-After`                  | Seconds to wait before retrying (set when 429) |

## 429 response body

When you're throttled, you receive an HTTP 429 with a JSON body describing which window tripped and when it resets.

```json theme={null}
{
  "status": 429,
  "detail": "Too many requests, buy more or upgrade your subscription, check header X-RateLimit-Reset. Will reset at 2024-11-17 07:10:53.",
  "urlForDocumentation": "https://docs.tic.io/throttling"
}
```

**Always read `Retry-After` (or `X-RateLimit-Reset`) and back off.** Do not retry in a tight loop. A well-behaved client reads these headers on every response and adapts pre-emptively.

## IP-based limits

Each API key is capped at a number of unique source IPs per month (default: **20**). This protects you if a key is leaked — an attacker's IP would count against the limit. The downstream IP is read from `X-Real-IP` or `X-Forwarded-For`.

If you run behind a load balancer or a pool of NAT'd outbound IPs, size your quota accordingly.

## Best practices

* **Use exponential backoff** when you get a `429`.
* **Monitor `X-RateLimit-Remaining-Minute`** to throttle proactively rather than reactively.
* **Consolidate traffic through few IPs** to stay under the unique-IP cap.
* **Prefer POST multi-search** where available to combine queries into fewer requests.