# Rate limits

> API request limits, how they are reported, and the provider limits CorrectInbox manages for you.

There are two kinds of limits to know about: the limit on calls to this **API**, and the activity limits the **provider** applies to each account.

## API rate limit

Calls to the CorrectInbox API are rate‑limited per API key. When you exceed it you get `429` with a `Retry-After` header (seconds).

```json
{
  "object": "error",
  "type": "rate_limited",
  "status": 429,
  "detail": "Too many requests. Retry after 12s.",
  "request_id": "req_a1b2c3"
}
```

Every response also carries limit headers:

| Header | Meaning |
| --- | --- |
| `X-RateLimit-Limit` | Requests allowed in the current window. |
| `X-RateLimit-Remaining` | Requests left in the window. |
| `X-RateLimit-Reset` | Unix time when the window resets. |

Back off when `Remaining` is low and always honour `Retry-After` on a `429`.

## Provider activity limits

Separately, the provider limits how much a single account can do per day — connection requests, messages, searches. **CorrectInbox manages these for you**: campaigns pace sending within conservative daily caps and add natural spacing, so accounts stay in good standing.

You don't set these limits, but you should design around them:

- To send more per day, spread a campaign across **more accounts** rather than pushing one account harder.
- Expect campaign throughput to be steady, not instant — that's deliberate.
- An account may still hit a provider limit; when it does, the action returns [`account_restricted`](/errors) and resumes later on its own.