The Brevo API enforces rate limits to ensure platform stability and fair resource allocation. Rate limits cap the number of API requests you can make within a given time period.
The API provides three rate limit tiers:
When you exceed a rate limit, the API returns a 429 Too Many Requests status code. Monitor rate limit headers in responses to track your usage and prevent errors.
Rate limits are expressed in two units
Some endpoints have both RPS and RPH limits. When both apply, you must respect both simultaneously.
POST /v3/smtp/email and GET /v3/smtp/blockedContacts, which have dedicated limits.POST /v3/smtp/email and GET /v3/smtp/blockedContacts, which have dedicated limits.POST /v3/smtp/email and GET /v3/smtp/blockedContacts, which have dedicated limits.When you exceed a rate limit, the API returns a 429 Too Many Requests status code. Follow these practices to avoid rate limit errors:
Calculate your rate limit allowance and distribute requests evenly across the time window. For example, with a limit of 1,000 RPS, you can send up to 60,000 requests per minute when distributed evenly.
If your application requires higher throughput, upgrade to an Enterprise plan for increased rate limits.
Instead of polling endpoints for statistics, implement webhooks to receive event-driven updates. This reduces API calls and improves efficiency.
The API includes rate limit headers in all responses to help you monitor usage and implement retry logic. See the rate limit headers guide for details.
Rate limits control request frequency, while platform quotas cap the number of objects you can create (campaigns, contacts, lists, etc.). See the platform quotas guide for object creation limits in Brevo.