Rate Limits
L’API di Brevo limita le richieste per endpoint, non per giorno. Ogni limite è un numero di richieste al secondo (RPS), all’ora (RPH) o entrambi, e quando valgono entrambi devi restare sotto tutti e due. Superare un limite restituisce 429 Too Many Requests.
Limiti del livello generale
Il livello generale si applica a ogni piano Brevo: Free, Starter, Standard, Professional ed Enterprise. Questi sono i limiti che Brevo pubblica per questo livello:
| Endpoint | Limite |
|---|---|
POST /v3/smtp/email, GET /v3/smtp/blockedContacts | 1.000 RPS, 3.600.000 RPH |
POST /v3/transactionalSMS/send | 150 RPS, 540.000 RPH |
Tutti gli endpoint sotto /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 |
Altri endpoint sotto /v3/smtp | 300 RPH |
Tutti gli endpoint sotto /v3/loyalty | 600 RPH |
| Tutti gli altri endpoint | 100 RPH |
Gli account Professional ed Enterprise possono usare il livello avanzato, che raddoppia la maggior parte di questi limiti. Gli account Enterprise possono usare il livello esteso, il più alto. Vedi Limiti globali per i tre livelli a confronto, e la pagina dei limiti di frequenza di Brevo per i valori aggiornati.
Header dei limiti di frequenza
Gli endpoint soggetti a limiti di frequenza restituiscono tre header:
x-sib-ratelimit-limit: 1000x-sib-ratelimit-remaining: 750x-sib-ratelimit-reset: 1x-sib-ratelimit-limit: richieste consentite nella finestra correntex-sib-ratelimit-remaining: richieste rimaste nella finestra correntex-sib-ratelimit-reset: tempo rimanente prima del reset della finestra, di solito in secondi
Best practice
- Monitorare gli header dei limiti di frequenza
- Implementare un backoff esponenziale per i tentativi successivi
- Distribuire le richieste in modo uniforme sulla finestra
- Mettere in cache le risposte quando possibile
- Usare i webhook invece del polling