Rate Limiting

Il rate limiting è un meccanismo di protezione che limita il numero di richieste API per unità di tempo, per garantire un utilizzo equo e la stabilità del sistema. Se superi il limite, ricevi una risposta HTTP 429 con header Retry-After.

Che cos'è il rate limiting?

Il rate limiting (limitazione della frequenza) controlla quante richieste API un client può effettuare in un determinato intervallo di tempo, ad esempio 100 richieste al minuto o 10.000 messaggi al giorno. Questi limiti proteggono l'infrastruttura API dal sovraccarico e garantiscono a tutti i clienti un accesso equo. Senza rate limiting, un singolo bot difettoso potrebbe inviare migliaia di richieste al secondo e rallentare il servizio per tutti gli altri.

Tecnicamente il rate limiting viene implementato per lo più tramite algoritmi Token Bucket o Sliding Window. Ogni API key dispone di un "budget" di richieste che si ricarica continuamente. Quando invii una richiesta, viene consumato un token. Esauriti tutti i token, devi attendere finché non ne vengono ricaricati di nuovi. SendSeven utilizza un sistema equo e trasparente, con messaggi di errore chiari e indicazioni sui tentativi successivi.

Perché esistono i rate limit?

Stabilità del sistema: le API condividono risorse (CPU, database, rete). Un singolo client "malevolo" potrebbe, senza limiti, bloccare l'intero sistema; il rate limiting previene scenari di tipo Denial of Service.

Utilizzo equo: tutti i clienti devono trarne pari beneficio. Se un cliente consuma il 90% della capacità, gli altri ne risentono. I rate limit garantiscono equità.

Controllo dei costi: cicli infiniti accidentali nel tuo codice potrebbero, senza limiti, generare milioni di richieste e i relativi costi. Il rate limiting funge da freno di emergenza.

Protezione dagli abusi: spammer e malintenzionati cercano spesso di inondare le API. I rate limit rendono questi attacchi non redditizi e rilevabili.

Gestire le risposte HTTP 429

Se superi un rate limit, l'API risponde con HTTP 429 (Too Many Requests). L'header della risposta contiene informazioni importanti:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1676543210

Retry-After: quanti secondi devi attendere prima che la richiesta successiva sia consentita.

X-RateLimit-Limit: il tuo limite complessivo (ad esempio 100 richieste al minuto).

X-RateLimit-Remaining: quante richieste sono ancora disponibili (qui: 0).

X-RateLimit-Reset: timestamp Unix che indica quando il limite verrà reimpostato.

Le applicazioni professionali implementano l'exponential backoff: dopo un errore 429 non attendi semplicemente 60 secondi fissi, ma raddoppi il tempo di attesa a ogni ulteriore errore (1s, 2s, 4s, 8s, …). Questo previene i problemi di "thundering herd", in cui migliaia di client riprovano contemporaneamente sovraccaricando di nuovo il sistema.

Rate limit con SendSeven

SendSeven adotta rate limit equi e generosi, sufficienti per la stragrande maggioranza dei casi d'uso. Valori tipici (a seconda del tuo piano):

• Richieste API: 100 richieste al minuto (per gli accessi in lettura)
• Invio messaggi: 1.000 messaggi all'ora (protezione anti-spam)
• Consegne webhook: 10 connessioni parallele

I limiti specifici sono indicati nella documentazione API su docs.sendseven.com. Se hai bisogno di limiti più elevati (ad esempio per importazioni di massa o campagne con oltre 100.000 destinatari), contatta l'assistenza: sono possibili adeguamenti personalizzati.

Best practice: implementa il rate limiting lato client già nella tua applicazione. Utilizza code (ad esempio Bull per Node.js, Celery per Python) per elaborare le richieste in modo controllato: così eviti gli errori 429 in partenza e ottimizzi i costi. Per l'invio in grandi volumi consigliamo inoltre la funzione integrata Reach (Campagne) di SendSeven, che gestisce il throttling automaticamente lato server.