# Rate limits

PaalChat's request limit and Meta's messaging limits.

> **In a nutshell:** 300 API requests per minute per product, 120 per business. Meta separately limits how many new conversations each business can start per day. Send in bulk from a queue and respect Retry-After.

## API requests

Each product may make **300 requests per minute**, across all its businesses.
Every response carries:

```http
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
```

Over the limit you get `429 rate_limited` with a `Retry-After` header (seconds).

Each business also has its own budget of **120 requests per minute** for its
`/businesses/{external_id}/...` endpoints, so one busy business cannot use up your
product's whole allowance. PaalTech can set a **daily message cap** for a business;
sends beyond it get `429 business_limit_reached` until the next day.

## Meta's messaging limits

Meta limits how many conversations a business can start in 24 hours. The tier is in
[`GET .../whatsapp`](/docs/api/get-whatsapp) as `messaging_limit`:

| Tier | Business-initiated conversations / 24 h |
|---|---|
| `TIER_250` | 250 |
| `TIER_1K` | 1,000 |
| `TIER_10K` | 10,000 |
| `TIER_100K` | 100,000 |
| `TIER_UNLIMITED` | Unlimited |

Meta raises the tier as the business sends good-quality messages. Sends beyond it
fail with a `message.status` callback. A `whatsapp.connection` callback reports tier
changes (events such as `UPGRADE`, `DOWNGRADE`).

## Quality

`quality_rating` (`GREEN`, `YELLOW`, `RED`) reflects how recipients react. Many
blocks and reports lower it and can lower the tier. Send only messages people expect.

## Bulk sending

- Queue sends in a background worker; pace them under your 300/minute budget.
- Give every message its own `reference` so a crashed batch can simply be resent.
- See the [bulk announcements](/docs/use-cases/bulk-announcements) use case.
