LinkedIn
Instagram
WhatsApp
Telegramma
Gmail
Prospettiva
Calendario di Google
Partecipare alla comunità SlackLimiti API di Gmail nel 2026: Quote, Limiti di frequenza, e Come Gestirli
Riferimento quote completo API Gmail, che copre limiti per minuto, per utente e giornalieri, costi unitari per metodo, gestione errori 429 e pattern di backoff esponenziale pronto per la produzione per utenti autenticati.
async function withBackoff(fn, maxRetries = 5) { let delay = 1000; for (let i = 0; i < maxRetries; i++) { try { return await fn(); } catch (err) { if (err.code !== 429) throw err; const jitter = Math.random() * 500; await sleep(delay + jitter); delay *= 2; } }}Ambito alla sessione dell'utente autenticato
Unipile non mantiene un archivio parallelo dei dati della casella di posta di Gmail. Tutto l'accesso alle e-mail è nell'ambito della sessione dell'utente autenticato chi ha concesso esplicitamente il consenso OAuth. Nessun dato viene memorizzato autonomamente oltre a quanto necessario per soddisfare tale richiesta specifica.
Intermediario tecnico indipendente
Unipile funge da intermediario tecnico indipendente, effettuando chiamate all'API di Gmail per conto di ciascun utente autenticato. Unipile non è un partner o affiliato di Google. Nessuna credenziale viene condivisa tra gli utenti. Ogni token OAuth appartiene esclusivamente all'utente che lo ha concesso.
Cadence è una decisione lato cliente
Unipile ripete i limiti di frequenza e i vincoli di quota dell'API Gmail come definiti da Google. La frequenza e il volume delle chiamate API effettuate per conto di ogni utente è un decisione lato cliente. Unipile gestisce gli errori di quota e applica una logica di backoff, ma la frequenza di chiamata rimane sotto il controllo dello sviluppatore.
Limiti API di Gmail a colpo d'occhio
Prima di scrivere una singola riga di logica di ripetizione dei tentativi, devi avere un quadro chiaro di tutti e tre gli assi di quota applicati da Google. La tabella seguente è il riferimento che aggiungerai ai preferiti: throughput per progetto, limiti per utente e tetto massimo giornaliero che si resetta a mezzanotte, ora del Pacifico.
| Limite | Valore | Dimensione | Appunti |
|---|---|---|---|
| Limite di frequenza API di Gmail (unità di quota) | 1.200.000 / min | Per il progetto GCP | Condiviso tra tutti gli utenti del progetto |
| Gmail API per le quote di utilizzo per utente | 6.000 giri/min | Per la casella di posta dell'utente | Il trigger più comune per un codice di stato 429 (Too Many Requests) in produzione |
| Quota giornaliera | 80.000.000 / giorno | Per il progetto GCP | Si resetta a mezzanotte ora del Pacifico |
| Quota di invio Gmail (Gmail gratuito) | 500 email / giorno | Indirizzo del mittente | 2.000 / giorno per Google Workspace |
| Richieste concorrenti per casella di posta | 50 | Per casella postale | Limite nascosto - attiva 429 indipendentemente dalla quota |
| Richieste batch per chiamata | 100 richieste | Per chiamata batch | Usa il batch per ridurre il consumo di unità di quota |
| Dimensione massima del messaggio (allegati) | 25 MB | Per messaggio | Inclusi intestazioni e corpo codificato |
Limiti di utilizzo della Gmail API (verificati per l'ultima volta a maggio 2026). I limiti sono soggetti a modifiche; controlla sempre la pagina delle quote della tua console GCP per i valori correnti del tuo progetto.
Le tre dimensioni delle quote
I limiti di utilizzo dell'API Gmail funzionano su tre assi indipendenti contemporaneamente. Una richiesta può essere bloccata anche se due dei tre sono a posto. Comprendere la separazione tra limiti per progetto, per utente e giornalieri è il primo passo per scrivere codice resiliente per qualsiasi utente autenticato.
Per progetto (GCP)
1.200.000 unità/minQuesto è il soffitto aggregato su tutti gli utenti all'interno di un singolo progetto GCP. Se hai 500 utenti autenticati che effettuano chiamate all'API Gmail contemporaneamente, il consumo della loro quota viene conteggiato in questo singolo "secchio". Colpirlo attiva un LimiteDiTassoSuperato 429. L'equivalente giornaliero è 80 milioni di unità, ricaricando a mezzanotte Pacifico.
Per utente (per casella di posta)
6.000 unità/minQuesto cappuccio si applica indipendentemente a ciascun utente autenticato. Anche se il tuo progetto ha spazio di quota disponibile, un singolo utente che bombarda la propria casella di posta con richieste di polling rapide attiverà un LimiteSuperato 429. Nelle app multi-tenant questo è il limite che viene attivato più spesso: è per utente, non condiviso.
Quota giornaliera
80.000.000 unità/giornoIl limite giornaliero è anche per progetto. A differenza delle finestre al minuto che si recuperano automaticamente dopo 60 secondi, il raggiungimento del quota giornaliera significa nessun ulteriore accesso all'API fino a mezzanotte Pacifico. L'errore è LimiteGiornalieroSuperato. Puoi richiedere un aumento della quota tramite la console GCP, che copriamo nella sezione multi-tenant.
Importante: I limiti di quotainodi dell'API di Gmail sopra indicati sono misurati in "unità di quota", non in conteggi grezzi di richieste. messages.invia Una chiamata costa 100 unità, mentre un messaggi.elenco costa solo 5. Ciò significa che il tuo budget per richieste pratiche varia in modo significativo a seconda dei metodi che chiami. Vedi la tabella dei costi unitari nella sezione successiva. Nota anche che Verifica dell'ambito OAuth gli errori dal flusso di consenso sono completamente separati da questi errori di quota di runtime.
Costo unitario per metodo
Non tutte le chiamate all'API di Gmail sono uguali. Google conta l'utilizzo della quota in "unità" astratte e ciascun metodo ha un costo diverso. Conoscere questi costi ti consente di calcolare la tua effettiva capacità di richiesta e ottimizzare gli endpoint che chiami. Il limite di 6.000 unità/min per utente dell'API Gmail si comporta in modo molto diverso a seconda del mix di chiamate.
| Metodo | Costo unitario | Richieste / min (per utente) | Suggerimento per l'ottimizzazione |
|---|---|---|---|
| messages.invia | 100 | 60 invii/min max | Costo più elevato - usa bozza + invia solo quando necessario |
| messages.insert | 25 | 240/min massimo | Inserimento nella casella di posta - meno di invio |
| threads.ottieni | 10 | 600 giri/min max | Preferisco threads.get a messages.get multipli. |
| messaggi.ottieni | 5 | 1.200 giri/min max | Aggiungi field=partial response per mantenere i costi a 5 |
| messaggi.elenco | 5 | 1.200 giri/min max | Usa history.list invece per i modelli di sincronizzazione |
| fili.elenco | 5 | 1.200 giri/min max | Impagina con maxResults per ridurre le chiamate |
| Elenco cronologia utenti | 2 | 3.000 giri/min max | Il migliore per la sincronizzazione incrementale - polling a costo più basso |
| etichette.elenco | 1 | 6.000 giri/min max | Metti in cache il risultato: le etichette cambiano raramente |
| messages.modifica | 5 | 1.200 giri/min max | Usa batchModify per aggiornamenti massivi delle etichette |
| messages.attachments.get | 5 | 1.200 giri/min max | Recupera gli allegati solo quando esplicitamente necessario |
Consiglio pro: Puoi usare la campi= parametro di query per risposte parziali su qualsiasi metodo. Richiedere solo i campi di cui la tua applicazione ha bisogno non riduce il costo unitario grezzo, ma riduce drasticamente la dimensione del payload della risposta e la latenza, un valore utile quando ti trovi vicino ai limiti di quota dell'API di Gmail. Prova le tue query in modo interattivo utilizzando Gmail OAuth Playground prima di inviare in produzione.
Il limite nascosto di 50 richieste-concorrenti-per-casella di posta
C'è un limite che la maggior parte dei tutorial su Gmail API non menzionano, eppure è la causa di misteriosi errori 429 nelle applicazioni multi-threaded o asincrone: Gmail applica un massimo di 50 richieste simultanee in volo per casella di posta. Questo limite è completamente indipendente dal tuo budget di unità di quota. Puoi trovarti a 500 unità di quota su 6.000 disponibili e ricevere comunque un 429 se hai 51 richieste aperte contemporaneamente sulla casella di posta dello stesso utente autenticato.
Perché questo sorprende gli sviluppatori
Framework asincroni come Node.js Promise.all() o Python asyncio.gather() rendere banalmente facile l'invio di oltre 100 richieste concorrenti. Quando si elabora una sincronizzazione di casella di posta e si espande per recuperare 200 messaggi contemporaneamente per conto di un singolo utente autenticato, Gmail vede 200 connessioni TCP aperte contro una casella di posta e limita immediatamente. La dashboard delle quote in GCP mostrerà molte unità rimanenti – il limite di 50 concorrenti non è esposto come metrica di quota.
Quando scatta
Il limite di 50 richieste concorrenti si attiva durante le operazioni di sincronizzazione di massa delle caselle di posta: recupero di thread di grandi dimensioni, download di allegati per molti messaggi contemporaneamente o paginazione attraverso un gran numero di etichette elaborando al contempo i risultati in modo concorrente. Qualsiasi codice che avvia più di 50 richieste in corso sulla stessa casella di posta raggiungerà questo limite.
Come risolvere
Utilizza un limitatore di concorrenza (semáforo) con ambito per utente autenticato. In Node.js, librerie come p-limite funziona bene. In Python, un asyncio.Semaphore(40) con un margine di sicurezza inferiore a 50 si evita l'esaurimento. Mantieni la tua concorrenza per utente a 40 o inferiore per margine di sicurezza.
// p-limit mantiene la concorrenza per utente sotto le 40import pLimite from 'p-limite';// Un'istanza di limitatore per utente autenticato (indicizzata per userId)const userLimiters = new Mappa();funzione getLimiter(userId) { se !limitatoriUtente.ha(userId)) { Limitatori utente.impostare(userId, pLimite(40)); } return Limitatori utente.ottenere(userId);}// Involgere ogni chiamata API di Gmail con il limiter dell'utenteasync function recuperaMessaggio(gmail, userId, messageId) { const limite = getLimiter(userId); return limit(() => gmail.users.messages.ottenere({ userId: 'me', id: messageId, campi: 'id,threadId,payload.headers,snippet' }));}Decodifica degli errori: 429 vs 403
L'API di Gmail restituisce due diversi codici di stato HTTP per problemi di quota e di accesso: 429 (Too Many Requests) e 403 (Forbidden). All'interno di questi due codici ci sono quattro motivi di errore distinti, ognuno con una causa principale diversa e una risoluzione diversa. Confonderli fa perdere tempo nel debug. Nota: errori di flusso OAuth come concessione_non_valida sono errori del token di aggiornamento - sono completamente separati da questi limiti di frequenza delle API di Gmail in fase di esecuzione.
| Codice HTTP | Motivo dell'errore | Causa | Risolvi |
|---|---|---|---|
| 429 | LimiteDiTassoSuperato | Superato il limite di 1,2 milioni di unità di quota/min a livello di progetto GCP. Tutti gli utenti autenticati nel progetto hanno collettivamente raggiunto il tetto massimo. | Backoff esponenziale + jitter. Aspetta e riprova. A lungo termine: frammenta in più progetti GCP o richiedi un aumento della quota. |
| 429 | LimiteSuperato | Un singolo utente autenticato ha superato 6.000 unità di quota/min, OPPURE ha superato 50 richieste concorrenti alla propria casella di posta. Il 429 più comune in produzione. | Coda per utente con limitatore di concorrenza. Applica il pattern semaforo (max 40 concorrenti). Aggiungi exponential backoff per il retry 429. |
| 403 | LimiteGiornalieroSuperato | Il progetto GCP ha consumato tutte le 80 milioni di unità di quota giornaliera prima di mezzanotte nel fuso orario del Pacifico. Non è possibile riprovare fino al ripristino. Questo è un blocco definitivo. | Aspetta il reset di mezzanotte del Pacifico o richiedere un aumento della quota tramite la console GCP. Implementare il budget giornaliero della quota per utente nella tua app. |
| 403 | Quota superata | È stata superata una sotto-quota specifica. Può anche indicare che la quota di invio di Gmail (500 email/giorno gratuite, 2.000 Workspace) è stata raggiunta per uno specifico indirizzo mittente. | Controlla quale quota. Per la quota di invio: cambia l'indirizzo di invio o attendi 24 ore. Per altre sotto-quote: identifica la metrica specifica nella dashboard delle quote di GCP. |
Limite massimo di progetto raggiunto: 1,2 milioni di unità quota/min per tutti gli utenti.
Correggere: Backoff esponenziale + jitter. A lungo termine: più progetti GCP o richiesta di aumento della quota.
Singolo utente ha superato 6.000 unità/min O 50 richieste concorrenti. Il 429 più comune.
Correggere: Coda per utente + semaforo (max 40 concorrenti). Aggiungere ritentativi con backoff.
Il progetto ha consumato tutte le 80 milioni di unità di quota giornaliera. Blocco totale fino a mezzanotte ora del Pacifico.
Correggere: Attendere il ripristino o richiedere un aumento della quota tramite la console GCP.
Quota di invio raggiunta per il mittente (500/giorno gratuiti, 2.000 Workspace).
Correggere: Controlla la dashboard GCP per la sottocuota specifica. Per inviare: cambia indirizzo o attendi 24 ore.
concessione_non_valida, accesso_negato, e client_non_valido provengono dal livello di scambio dei token OAuth, non dall'applicazione delle quote dell'API di Gmail. Sono trattati separatamente nella Guida agli errori di Google OAuth. Se vedi un 401 Non autorizzato, anche questo è un problema di autenticazione: controlla il tuo Verifica app OAuth stato e se il Il token di aggiornamento è scaduto. Gestione pronta per la produzione: backoff esponenziale + jitter
Il backoff esponenziale è l'unica risposta corretta a un 429 dalla Gmail API. Riprovare immediatamente peggiora il problema: accumuli altre richieste su una finestra di quota già limitata. L'aggiunta di un jitter casuale previene il problema del "thundering herd" (branco tuonante), in cui tutti i client di una flotta riprovano esattamente nello stesso momento. Di seguito sono riportate implementazioni complete e testate in produzione in Node.js e Python.
Ritardo iniziale
Inizia con 1.000 ms al primo tentativo. Non ritentare immediatamente dopo un 429.
Moltiplicatore esponenziale
Ritardo doppio ad ogni tentativo: 1s, 2s, 4s, 8s, 16s. Limite massimo a 32-64 secondi.
Jitter casuale
Aggiungi un jitter casuale di 0-500 ms per prevenire tentativi di sincronizzazione tra worker concorrenti.
// gmail-backoff.js - production-ready exponential backoff + jitter// Handles rateLimitExceeded and userRateLimitExceeded (gmail api rate limits)const sleep = (ms) => new Promise(r => setTimeout(r, ms));async function withGmailBackoff(fn, { maxRetries = 5, initialDelay = 1000, maxDelay = 32000, jitter = 500} = {}) { let delay = initialDelay; for (let attempt = 0; attempt < maxRetries; attempt++) { try { return await fn(); } catch (err) { const code = err?.code || err?.response?.status; const reason = err?.errors?.[0]?.reason || ''; // Only retry on quota errors - not on 403 dailyLimitExceeded const isRetryable = code === 429 || reason === 'rateLimitExceeded' || reason === 'userRateLimitExceeded'; if (!isRetryable || attempt === maxRetries - 1) throw err; const wait = Math.min(delay + Math.random() * jitter, maxDelay); await sleep(wait); delay *= 2; } }}// Usage: on behalf of each authenticated userconst message = await withGmailBackoff(() => gmail.users.messages.get({ userId: 'me', id: messageId }));# gmail_backoff.py - backoff esponenziale + jitter per i limiti di frequenza dell'API di Gmailimport asincrono, casualefrom googleapiclient.errors import Errore HTTPasincrono def con_ritardo_gmail( fn, tentativi_massimi=5, ritardo_iniziale=1.0, max_ritardo=32.0, tremolio0.5): "Esegui il wrapping di qualsiasi chiamata API di Gmail con backoff esponenziale + jitter casuale. Gestisce i limiti delle richieste dell'API Gmail: rateLimitExceeded e userRateLimitExceeded. """ ritardo = ritardo_iniziale per tentativo in range(max_tentativi): tentare: return fn() La funzione # è una chiamata sincrona del client Gmail tranne Errore HTTP come e: stato = e.resp.status ragione = e.error_details[0].ottenere('ragione', '') se e.dettagli_errore altro '' # Riprova su 429; NON riprovare in caso di dailyLimitExceeded ritentabile = stato == 429 o ragione in ( 'limiteRaggiunto', 'limiteDiRichiesteSuperato' ) se non ritentabile o tentativo == tentativi_massimi - 1: salire aspettare = minuto(ritardo + casuale.divisa(0, jitter), ritardo massimo) await asyncio.dormire(aspettare) ritardo *= 2Strategie per rimanere sotto il limite
Backoff gestisce le situazioni di emergenza. Queste strategie proattive ti impediscono fin dall'inizio di raggiungere i limiti di quota dell'API di Gmail. Sono elencate in ordine decrescente in base al loro impatto sul consumo della quota. Combinandone due o tre è possibile ridurre la spesa unitaria dell'80% in carichi di lavoro tipici caratterizzati da un'elevata attività di lettura.
Coda per utente autenticato
Mantieni una coda di richieste separata per utente autenticato. Non mescolare mai richieste di utenti diversi in un pool condiviso. Questo isola l'esposizione al limite di frequenza per utente e consente una coda equa: se un utente attiva un 429, solo la sua coda si interrompe, gli altri continuano a piena velocità. Usa Redis o una coda in memoria con un bucket di token per utente.
Usa history.list invece di messages.list per la sincronizzazione
Sondaggio messaggi.elenco a tempo è l'errore più comune nei limiti di utilizzo dell'API di Gmail. Elenco cronologia utenti costa solo 2 unità (rispetto a 5 per messages.list) e restituisce solo il delta rispetto all'ultimo punto di sincronizzazione. Per le applicazioni con un carico di lettura elevato che sincronizzano caselle di posta di grandi dimensioni, questa opzione da sola può ridurre il consumo di quota del 60%. Memorizza il idStoria da ogni risposta come il tuo cursore. Coppia con notifiche push di Gmail (Pub/Sub) per la sincronizzazione quasi in tempo reale.
Chiamate API in batch
La Gmail API supporta richieste batch: combina fino a 100 richieste individuali in una singola chiamata HTTP. Ogni sotto-richiesta conta comunque il suo normale costo unitario, ma si riduce l'overhead TCP e gli "slot" di limitazione della frequenza consumati. Questo è particolarmente efficace per messaggi.ottieni operazioni in cui è necessario recuperare molti messaggi da un delta di sincronizzazione. Controlla Guida batch di Gmail per i dettagli di implementazione.
Utilizza risposte parziali (fields=)
Ogni metodo dell'API Gmail supporta il campi= parametro per richiedere solo le proprietà necessarie. Sebbene ciò non riduca il costo unitario della richiesta, riduce il carico utile della risposta del 60-90% e migliora la latenza. Per un messaggi.ottieni restituendo solo id,id del thread,payload.intestazioni,snippet, il payload scende da oltre 40KB a meno di 2KB. Meno rete = iterazioni più veloci = più margine prima di raggiungere il limite del quota giornaliera dell'API di Gmail.
Push vs Poll: il modello di sincronizzazione giusto
5 unità per poll + N x 5 unità per recuperare ogni nuovo messaggio. Per 100 utenti x intervallo di 30 secondi = 1 milione di unità/ora solo per l'overhead del polling.
2 unità per ogni interrogazione; restituisce solo le modifiche apportate dall'ultima sincronizzazione. 60% è più economico rispetto all'interrogazione di messages.list per ottenere lo stesso risultato.
Costo zero per le quote di consegna. Google invia una notifica quando una casella postale cambia: recuperi solo il delta. Richiede un endpoint webhook pubblico. Ideale per applicazioni quasi in tempo reale.
Scalabilità multi-tenant e richiesta di aumento di quota
Una volta superato un piccolo numero di account collegati, le quote dell'API di Gmail diventano una questione di architettura. Questa sezione copre lo sharding dei progetti GCP per implementazioni su larga scala e il processo passo-passo per richiedere un aumento delle quote dell'API di Gmail a Google.
Suddivisione in shard del progetto GCP
Il limite di quota di 1,2 milioni di unità al minuto è per progetto GCP. Se hai 1.000 utenti autenticati che eseguono la sincronizzazione attiva, puoi dividerli tra due progetti GCP per raddoppiare la capacità effettiva a livello di progetto. Ciascun progetto necessita delle proprie credenziali client OAuth e schermata di consenso. Gli utenti collegati al progetto A non possono utilizzare la quota del progetto B. Questo è particolarmente utile per scenari di sincronizzazione di posta elettronica ad alto volume in cui il limite massimo della quota giornaliera dell'API Gmail è una preoccupazione. Monitora l'utilizzo della tua quota nella console GCP per sapere quando è necessario lo sharding.
Richiesta di aumento della quota
Google concede aumenti di quote su richiesta, ma richiedono tempo (tipicamente 3-5 giorni lavorativi per la revisione iniziale, fino a 2 settimane per aumenti consistenti). Invia tramite la Console GCP: API e Servizi > Gmail API > Quote > "Richiedi una quota maggiore". Google richiede una giustificazione dettagliata. Elementi chiave da includere: utenti attivi giornalieri stimati, richieste medie per utente al giorno, ripartizione per metodo (messages.invia vs messaggi.elenco ecc.), e il caso d'uso di produzione. Richieste vaghe vengono rifiutate. Fornire numeri concreti dalla telemetria del tuo staging.
Monitorare e pianificare la quota giornaliera
Implementa il monitoraggio del budget delle quote per utente autenticato nel tuo data layer. Tieni traccia unitàDiQuotaUtilizzate per ogni utente al giorno. Quando un utente si avvicina a 70-80% del proprio budget giornaliero individuale, passare dalla modalità Active Sync alla modalità solo push per quell’utente per il resto della giornata. Ciò impedisce che un singolo utente con volumi elevati esaurisca una quota giornaliera a livello di progetto sproporzionata. La cadenza con cui si assegna la quota per utente è un decisione lato cliente in termini di progettazione della tua applicazione.
Cosa includere nella richiesta di aumento della quota
Utilizzo iniziale di base: "Attualmente utilizziamo X milioni di unità al giorno per Y utenti attivi."
Proiezione di crescita: "Tra 6 mesi ci aspettiamo Z utenti, il che richiederà circa W milioni di unità al giorno."
Caso d'uso: "Il nostro prodotto legge Gmail per attivare [sincronizzazione CRM / casella di posta ATS / analisi delle email]. Gli utenti si autenticano individualmente tramite OAuth."
Suddivisione del metodo: ""Metodi principali: messages.list (40%), messages.get (35%), history.list (20%), messages.send (5%).""
Come Unipile gestisce la limitazione di Gmail per conto dell'utente autenticato
La costruzione di tutta l'infrastruttura di throttling descritta in questa guida - code per utente, semafori, backoff esponenziale, budgeting delle quote giornaliere, gestione dei progetti GCP - richiede settimane e una manutenzione continua. Unipile gestisce tutto questo come intermediario tecnico indipendente, così il tuo team si concentra sulla logica del prodotto, non sull'idraulica dei quote. L'accesso all'API di Gmail tramite Unipile non è affiliato a Google, né approvato o sponsorizzato da Google.
Backoff esponenziale gestito + jitter
Ogni chiamata all'API di Gmail effettuata per conto di ogni utente autenticato passa attraverso il layer di backoff di Unipile. gli errori 429 sono trasparenti al tuo codice: Unipile ritenta automaticamente con backoff esponenziale completo e jitter, mostrando solo il successo finale o un errore pulito dopo il numero massimo di tentativi.
Isolamento della coda per utente
Unipile mantiene un rigoroso isolamento per utente. Un utente autenticato con throttling non influisce mai sulla produttività di un altro utente. Ciascun account collegato ha la propria coda con limiti di concorrenza individuali, garantendo un'equa allocazione delle risorse tra tutti i tuoi utenti.
Modello unificato: Gmail + Outlook + IMAP
La stessa logica di throttling si applica uniformemente a Gmail, Prospettiva (Microsoft 365 e Exchange Online), e IMAP. La tua applicazione utilizza un'unica API standardizzata indipendentemente dal provider di posta elettronica collegato dall'utente autenticato. Nessun codice di limitazione della frequenza specifico del provider da mantenere.
Conforme alla GDPR, allineato a SOC2
I dati accessibili tramite Unipile sono nell'ambito della sessione dell'utente autenticato chi ha concesso il consenso OAuth. Nessun archivio parallelo, nessun immagazzinamento a lungo termine dei dati della mailbox oltre le esigenze di sessione. Allineamento GDPR e SOC2 integrato.
// Con Unipile: niente backoff, niente semafori, niente tracciamento delle quoteUnipile gestisce tutti i limiti di frequenza dell'API di Gmail come intermediario tecnico indipendenteimport UnipileClient from '@unipile/node-sdk';const cliente = new UnipileClient({ apiKey: process.env.UNIPILE_API_KEY, baseUrl: 'https://api3.unipile.com:13613'});// Elenca messaggi per l'account Gmail collegato di un utente autenticatoLimitazione, backoff e isolamento per utente gestiti lato server da Unipileasync function getRecentEmails(idConto) { const messaggi = await client.messaging.elencaMessaggi({ ID_account: accountID, account collegato dell'utente autenticato limite: 25 }); return messaggi;}// Funziona in modo identico per Gmail, Outlook e account collegati IMAP// Stesso codice, nessuna gestione dei limiti di frequenza specifici del providerLimiti di frequenza dell'API Gmail - FAQ
Risposte alle domande più frequenti sui limiti di frequenza dell'API Gmail, unità di quota, errori 429 e scaling della tua integrazione.
L'API di Gmail impone limiti su tre dimensioni contemporaneamente. A livello di progetto: 1.200.000 unità di quota al minuto condiviso tra tutti gli utenti, e 80.000.000 unità di quota al giorno. A livello di utente: 6.000 unità di quota al minuto per cassetta postale. C'è anche un limite nascosto al 50 richieste concorrenti per casella di posta che può innescare una 429 anche quando sei ben al di sotto del limite massimo di unità. Ogni metodo ha un costo unitario diverso - messages.invia costa 100 unità mentre messaggi.elenco costa solo 5.
Implementare exponential backoff con jitterinizia a 1.000 ms al primo tentativo, raddoppia ad ogni tentativo, aggiungi uno jitter casuale di 0-500 ms, con un limite massimo di 32.000 ms. Non ritentare immediatamente. Aggiungi un limitatore di concorrenza con ambito per utente autenticato, mantenendo le richieste in corso al di sotto di 40 per casella di posta. Utilizzare un coda per utente in modo che un utente limitato non ne impatti altri. A lungo termine, passare il polling da messaggi.elenco (5 unità) a storia.elenco (2 unità) e considerare le notifiche push di Gmail per eliminare completamente il polling.
La Gmail API la quota giornaliera è di 80.000.000 unità di quota per progetto GCP, e si reimposta a mezzanotte ora del Pacifico. Questo limite restituisce un 403 Limite giornaliero superato errore - a differenza degli errori 429 al minuto, questo non può essere ritentato fino al reset giornaliero. Per aumentarlo: Console GCP > API e Servizi > Gmail API > Quote > Richiedi quota maggiore. Includi l'utilizzo attuale, le proiezioni di crescita e il tuo caso d'uso. L'approvazione richiede in genere 3-5 giorni lavorativi.
La Gmail Invio quota è di 500 email al giorno per account Gmail gratuiti e 2.000 email al giorno per gli account Google Workspace. Questo limite è per indirizzo mittente ed è separato dal budget delle unità di quota API. Ciascuna messages.invia la chiamata costa anche 100 unità di quota, quindi con un limite di 6.000 unità/min per utente puoi inviare al massimo 60 e-mail al minuto prima di raggiungere il limite di velocità dell'API Gmail per utente, ma la soglia giornaliera di 500/2.000 verrà probabilmente raggiunta prima per casi d'uso tipici.
LimiteDiTassoSuperato significa che l'intero progetto GCP ha superato 1.200.000 unità di quota/min - tutti gli utenti autenticati insieme. LimiteSuperato significa che un singolo utente ha superato 6.000 unità di quota al minuto o inviato più di 50 richieste concorrenti alla loro casella di posta. Nelle app multi-tenant di produzione, LimiteSuperato è molto più comune perché i singoli utenti possono raggiungere autonomamente i loro limiti indipendentemente dallo spazio di manovra a livello di progetto. Entrambi restituiscono HTTP 429 e rispondono entrambi al backoff esponenziale.
Naviga verso GCP Console > API e servizi > Gmail API > Quote e fai clic su "Richiedi quota maggiore". La tua richiesta deve includere una giustificazione concreta: base di utilizzo giornaliero attuale, proiezione della crescita utenti a 6 mesi, descrizione di come gli utenti si autenticano individualmente tramite OAuth e una ripartizione dei metodi API per proporzione. Le richieste vaghe verranno respinte. Assicurati anche che la tua app sia OAuth verificato - Le app non verificate sono limitate a 100 utenti di test indipendentemente dalla quota. La revisione richiede in genere 3-5 giorni lavorativi per la risposta iniziale.
messages.invia costi 100 unità di quota per chiamata - il metodo più costoso dell'API Gmail. Con il limite per utente di 6.000 unità/min, puoi inviare al massimo 60 email al minuto per utente autenticato. A confronto: messaggi.ottieni costa 5 unità (1.200 chiamate/min), storia.elenco costa 2 unità (3.000 chiamate/min), e etichette.elenco costa 1 unità (6.000 chiamate/min). Per campagne di outreach ad alto volume, valuta se il tuo caso d'uso richiede davvero di effettuare chiamate messages.invia o se la creazione di bozze e l'invio in batch sia più efficiente.
Unipile accede solo ai dati esplicitamente richiesti dalla tua applicazione, nell'ambito della sessione dell'utente autenticato chi ha concesso il consenso OAuth. Non esiste un archivio parallelo, né uno spazio di archiviazione indipendente a lungo termine dei dati della casella di posta oltre a quanto necessario per soddisfare la richiesta API corrente. I dati di ciascun utente autenticato sono isolati: Unipile agisce come intermediario tecnico indipendente solo per conto di quello specifico utente.
La frequenza e il volume delle chiamate API effettuate per conto di ciascun utente autenticato è un decisione lato cliente. Unipile gestisce l'infrastruttura di backoff e accodamento, ma è la tua applicazione a determinare la frequenza di richiesta dei dati. Unipile segnala gli errori di quota in modo trasparente e applica la logica di ripetizione dei tentativi, ma la cadenza complessiva delle chiamate, inclusi quanti utenti si sincronizzano contemporaneamente e con quale frequenza, rimane sotto il tuo controllo come sviluppatore che implementa soluzioni basate su Unipile.
No. Unipile è non affiliato, approvato o sponsorizzato da Google. Unipile è un intermediario tecnico indipendente che effettua chiamate API Gmail per conto di utenti autenticati che hanno concesso individualmente il consenso OAuth tramite i propri account Google. Gmail è un marchio di Google LLC. Tutte le quote, i limiti di frequenza e le policy delle API Gmail sono definiti da Google e soggetti a modifiche indipendentemente da Unipile.
Domande sui limiti dell'API di Gmail e sull'integrazione con Unipile? Il nostro team è qui per aiutarti.
La Guida Completa delle API Email per Sviluppatori
I limiti di Gmail sono una parte del quadro dell'API email. La guida Pillars copre le integrazioni Gmail, Outlook e IMAP end-to-end.
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR