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:
Endpoint | Rate Limiting | Granularity per second |
---|---|---|
POST /v3/smtp/email GET /v3/smtp/blockedContacts | 3 600 000 RPH | 1000 RPS |
POST /v3/transactionalSMS/sms | 540 000 RPH | 150 RPS |
POST /v3/events | 36 000 RPH | 10 RPS |
**All endpoints under/v3/smtp/{…}) | 300 RPH | - |
All endpoints under /v3/contacts/{…} | 36 000 RPH | 10 RPS |
All other endpoints | 100 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.
Endpoint | Rate Limiting | Granularity per second |
---|---|---|
POST /v3/smtp/email |GET /v3/smtp/blockedContacts | 7 200 000 RPH | 2000 RPS |
POST /v3/transactionalSMS/sms | 720 000 RPH | 200 RPS |
POST /v3/events | 72 000 RPH | 20 RPS |
**All endpoints under/v3/smtp/{…} | 600 RPH | - |
All endpoints under /v3/contacts/{…} | 72 000 RPH | 20 RPS |
All other endpoints | 200 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 name | Description |
---|---|
x-sib-ratelimit-limit | This is the limit of the requests before a 429 status code |
x-sib-ratelimit-remaining | This is the remaining limit of requests |
x-sib-ratelimit-reset | Shows the unit in the granularity the RL is set. In the case below it is 999 available in the current 1 second |
Updated 2 months ago