---
title: "Rate Limits | Tajo"
description: "Understanding Brevo API rate limits and best practices"
url: https://tajo.io/docs/rate-limits/
markdown: https://tajo.io/docs/rate-limits.md
lang: en-US
author: "Set Noa"
author_url: https://tajo.io/set-noa/
---

# Rate Limits

[Set Noa](https://tajo.io/set-noa/)

The Brevo API limits requests per endpoint, not per day. Each limit is a number of requests per second (RPS), per hour (RPH), or both, and when both apply you must stay under both. Exceeding a limit returns `429 Too Many Requests`.

## Limits on the general tier

The general tier applies to every Brevo plan: Free, Starter, Standard, Professional and Enterprise. These are the limits Brevo publishes for it:

| Endpoint | Limit |
| --- | --- |
| `POST /v3/smtp/email`, `GET /v3/smtp/blockedContacts` | 1,000 RPS, 3,600,000 RPH |
| `POST /v3/transactionalSMS/send` | 150 RPS, 540,000 RPH |
| All endpoints under `/v3/contacts` | 10 RPS, 36,000 RPH |
| `POST /v3/events` | 10 RPS, 36,000 RPH |
| `POST /v3/orders/status` | 5 RPS, 18,000 RPH |
| `POST /v3/products` | 2 RPS, 7,200 RPH |
| `GET /v3/smtp/emails` | 2 RPS, 7,200 RPH |
| Other endpoints under `/v3/smtp` | 300 RPH |
| All endpoints under `/v3/loyalty` | 600 RPH |
| All other endpoints | 100 RPH |

Professional and Enterprise accounts can use the advanced tier, which doubles most of these limits. Enterprise accounts can use the extended tier, the highest. See [Global limits](https://tajo.io/docs/rate-limits/global-limits/) for the three tiers side by side, and Brevo’s [rate limits page](https://developers.brevo.com/docs/api-limits) for the current figures.

## Rate Limit Headers

Rate-limited endpoints return three headers:

```
x-sib-ratelimit-limit: 1000
x-sib-ratelimit-remaining: 750
x-sib-ratelimit-reset: 1
```

- `x-sib-ratelimit-limit`: requests allowed in the current window
- `x-sib-ratelimit-remaining`: requests left in the current window
- `x-sib-ratelimit-reset`: time until the window resets, usually in seconds

## Best Practices

- Monitor rate limit headers
- Implement exponential backoff for retries
- Spread requests evenly across the window
- Cache responses when possible
- Use webhooks instead of polling