---
title: "Rate Limits | Tajo"
description: "Comprendi i limiti di frequenza dell'API Brevo e le best practice"
url: https://tajo.io/it/docs/rate-limits/
markdown: https://tajo.io/it/docs/rate-limits.md
lang: it-IT
author: "Set Noa"
author_url: https://tajo.io/it/set-noa/
robots: noindex
---

Richiedi l’accesso anticipato

Inserisci il tuo nome e indirizzo email aziendale. Ti invieremo un link per confermare la richiesta di accesso a Tajo.

# Rate Limits

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

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](https://tajo.io/it/docs/rate-limits/global-limits/) per i tre livelli a confronto, e la [pagina dei limiti di frequenza](https://developers.brevo.com/docs/api-limits) 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: 1000
x-sib-ratelimit-remaining: 750
x-sib-ratelimit-reset: 1
```

- `x-sib-ratelimit-limit`: richieste consentite nella finestra corrente
- `x-sib-ratelimit-remaining`: richieste rimaste nella finestra corrente
- `x-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