API rate limits

You will find here all the information regarding how to properly execute API calls in bulks.

We have redefined our rate limit policies in 2023 to better fit your needs and scale as you grow. In some cases it might require you to adapt your integration to these changes.

Our public API is a service accessible to all Brevo users, we want to provide the best possible experience when you integrate to our platform. In order to ensure this we have put in place some limits to the number of API requests that can be executed over a period of time.

General Rate Limiting

Our endpoint list has been optimised in such way that we ensure the critical routes can efficiently handle as many requests as possible without compromising stability. This translates to the following numbers:

EndpointRate LimitingGranularity per second
POST /v3/smtp/email
GET /v3/smtp/blockedContacts
3 600 000 RPH 1000 RPS
POST /v3/transactionalSMS/sms540 000 RPH150 RPS
POST /v3/events36 000 RPH10 RPS
**All endpoints under/v3/smtp/{…})300 RPH-
All endpoints under
/v3/contacts/{…}
36 000 RPH10 RPS
All other endpoints100 RPH-

**This rule excludes the routes POST /v3/smtp/email and GET /v3/smtp/blockedContacts which have their own dedicated rate limits.

RPS: HTTP requests per second
RPH: HTTP requests per hour


Enterprise Rate Limiting

If your account is under an Enterprise plan all your API keys will have access to our extended rate limit policy which allows to scale your application accordingly.

EndpointRate LimitingGranularity per second
POST /v3/smtp/email |
GET /v3/smtp/blockedContacts
7 200 000 RPH2000 RPS
POST /v3/transactionalSMS/sms720 000 RPH200 RPS
POST /v3/events 72 000 RPH20 RPS
**All endpoints under/v3/smtp/{…}600 RPH-
All endpoints under
/v3/contacts/{…}
72 000 RPH20 RPS
All other endpoints200 RPH-

**This rule excludes the routes POST /v3/smtp/email and GET /v3/smtp/blockedContacts which have their own dedicated rate limits.

RPS: HTTP requests per second
RPH: HTTP requests per hour

Rate Limit Add-On

If your account is under an enterprise plan and you would still require more throughput for your API operations you can apply for a rate limit add-on on top of your existing policy. This will allow you to scale your integration way further than conventional limits.

📘

Request an extended rate limit

If your integrations require an increased rate limit policy please reach out to our sales team here. We will be glad to scale the rate limit to fit your needs.


How to prevent my API requests from being rejected ?

If you execute request bursts in shorter timeframes other than the specified above you might get as a result a 429 status code or "Too many requests". This means you're hitting the limit for the number of requests allowed for a unique endpoint. Here are some recommendations on how to prevent this error:

1- Make sure you properly calculate your rate limit allowance. You need to send your bulk requests equally distributed through the specified time granularity. E.g 1000 RPS = up to 60K requests per minute.

2- Considering moving to a higher rate limit tier if you application needs to scale. You will need an Enterprise plan. You can contact our sales team here .

3- If you would like to fetch the statistics for your marketing or transactional email integration. We encourage you implement an event driven mechanism by making use of our webhook platform. You can learn more about this topic here.

Rate limit reset

When the user receives a 429 status code for rate limiting, they receive headers which show the remaining time until the limit is reset. The headers are mentioned below

Header nameDescription
x-sib-ratelimit-limitThis is the limit of the requests before a 429 status code
x-sib-ratelimit-remainingThis is the remaining limit of requests
x-sib-ratelimit-resetShows the unit in the granularity the RL is set. In the case below it is 999 available in the current 1 second


What’s Next