LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Agenda
Word lid van de Slack-gemeenschapGmail API Limieten in 2026: Quota's, Snelheidslimieten, en Hoe ermee om te gaan
Volledige referentie van Gmail API quota, inclusief limieten per minuut, per gebruiker, en dagelijks, kosten per methode, 429 error handling, en een productie-klaar exponentieel backoff-patroon voor geauthenticeerde gebruikers.
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; } }}Toegewezen aan de sessie van de geauthenticeerde gebruiker
Unipile onderhoudt geen parallel archief van Gmail mailboxgegevens. Alle e-mailtoegang is gebonden aan de sessie van de geauthenticeerde gebruiker die expliciet toestemming heeft gegeven voor OAuth. Er worden geen gegevens onafhankelijk opgeslagen, behalve wat nodig is om die specifieke aanvraag te verwerken.
Onafhankelijke technische tussenpersoon
Unipile fungeert als een onafhankelijke technische tussenpersoon, Gmail API-aanroepen uitvoeren namens elke individuele geauthenticeerde gebruiker. Unipile is geen partner of gelieerde onderneming van Google. Er worden geen referenties gedeeld tussen gebruikers. Elke OAuth-token behoort uitsluitend toe aan de gebruiker die deze heeft verleend.
Cadence is een beslissing aan de kant van de klant
Unipile beheert de rate limits en quota beperkingen van de Gmail API, zoals gedefinieerd door Google. De frequentie en het volume van API-aanroepen die worden gedaan namens elke gebruiker is een beslissing aan klantzijde. Unipile oppervlakte quotafouten en past backoff-logica toe, maar het aanroeper-ritme blijft onder controle van de ontwikkelaar.
Gmail API-limieten in één oogopslag
Voordat u ook maar één regel retry-logica schrijft, moet u een duidelijk beeld hebben van alle drie de quota-assen die Google hanteert. De onderstaande tabel is de referentie die u zult bewaren: doorvoer per project, limieten per gebruiker en de dagelijkse limiet die om middernacht Pacific Time wordt gereset.
| Limiet | Waarde | Afmeting | Notities |
|---|---|---|---|
| Gmail API quotabeperking (quotum-eenheden) | 1.200.000 / min | Per GCP-project | Gedeeld met alle gebruikers in het project |
| Gmail API per gebruiker limiet | 6.000 / min | Per gebruikersmailbox | Meest voorkomende trigger voor 429 in productie |
| Dagelijkse quotum | 80.000.000 / dag | Per GCP-project | Wordt gereset om middernacht Pacifische tijd |
| Gmail verzendquota (gratis Gmail) | 500 e-mails / dag | Per afzenderadres | €2.000 per dag voor Google Workspace |
| Gelijktijdige verzoeken per postvak | 50 | Per mailbox | Verborgen limiet - activeert 429 ongeacht de quota |
| Batchverzoeken per aanroep | 100 verzoeken | Per batchaanroep | Batch gebruiken om het verbruik van quota-eenheden te verminderen |
| Maximale berichtgrootte (bijlagen) | 25 MB | Per bericht | Inclusief headers en gecodeerde hoofdtekst |
Bron: Google Developers documentatie, Gmail API - Gebruikslimieten (laatst geverifieerd mei 2026). Limieten kunnen veranderen; controleer altijd de Quota-pagina van uw GCP-console voor de actuele waarden voor uw project.
De drie quotumdimensies
Gmail API-gebruikslimieten werken gelijktijdig op drie onafhankelijke assen. Een verzoek kan worden geweigerd, zelfs als twee van de drie geen problemen vertonen. Het begrijpen van de scheiding tussen limieten per project, per gebruiker en dagelijkse limieten is de eerste stap naar het schrijven van veerkrachtige code voor elke geauthenticeerde gebruiker.
Per project (GCP)
1.200.000 eenheden/minDit is de totale plafond over alle gebruikers binnen één GCP-project. Als je 500 geauthenticeerde gebruikers hebt die tegelijkertijd Gmail API-aanroepen doen, telt het quotagebruik van al hun aanroepen tegen deze enkele bucket. Het raken ervan activeert een rateLimitExceeded 429. Het dagelijkse equivalent is 80 miljoen stuks, wordt elke middernacht opnieuw ingesteld op Pacific Time.
Per gebruiker (per postvak)
6.000 eenheden/minDeze dop is onafhankelijk van toepassing op elke geauthenticeerde gebruiker. Zelfs als uw project quotumruimte heeft, zal een enkele gebruiker die zijn eigen mailbox herhaaldelijk bevraagt met snelle polling een GebruikerRateLimitOverschreden 429. In multi-tenant apps is dit de limiet die het vaakst wordt bereikt: deze is per gebruiker, niet gedeeld.
Dagelijkse quotum
80.000.000 eenheden/dagDe dagelijkse limiet is ook per project. In tegenstelling tot de per-minuut vensters die automatisch herstellen na 60 seconden, bereikt het dagelijks quotum betekent dat er tot middernacht Pacific Time geen toegang meer is tot de API. De foutmelding is dagelijkslimietOverschreden. U kunt een verhoging van uw quota aanvragen via de GCP-console – daar gaan we in het gedeelte over multi-tenant op in.
Belangrijk: De hierboven genoemde limieten van de Gmail API worden gemeten in "quota-eenheden", niet in ruwe aantallen verzoeken. Een berichten.verzenden een oproep kost 100 eenheden, terwijl een Berichtenlijst kost slechts 5. Dit betekent dat uw praktische budget voor aanvragen aanzienlijk varieert, afhankelijk van welke methoden u aanroept. Zie de tabel met eenheidskosten in de volgende sectie. Merk ook op dat OAuth-bereikverificatie fouten in de toestemmingsstroom staan volledig los van deze runtime quota-fouten.
Quotumeenheidkosten per methode
Niet alle Gmail API-aanroepen zijn gelijk. Google telt quota-gebruik in abstracte "eenheden" en elke methode heeft een andere kostenpost. Het kennen van deze kosten stelt u in staat om uw echte aanvraagcapaciteit te berekenen en te optimaliseren welke eindpunten u aanroept. De Gmail API-limiet per gebruiker van 6.000 eenheden/min gedraagt zich heel anders, afhankelijk van uw mix van aanroepen.
| Methode | Kostprijs per eenheid | Verzoeken / min (per gebruiker) | Optimalisatietip |
|---|---|---|---|
| berichten.verzenden | 100 | 60 verzendingen/min max | Hoogste kosten - gebruik concept + alleen verzenden indien nodig |
| messages.invoegen | 25 | 240/min max | Invoegen in mailbox - lager dan verzenden |
| threads.ophalen | 10 | 600/min max | Geef de voorkeur aan threads.get boven meerdere messages.get |
| berichten.ophalen | 5 | 1.200/min max | Voeg velden=gedeeltelijke reactie toe om de kosten op 5 te houden |
| Berichtenlijst | 5 | 1.200/min max | Gebruik history.list in plaats van sync patterns |
| threads.lijst | 5 | 1.200/min max | Pagineren met maxResults om aanroepen te verminderen |
| gebruikers.geschiedenis.lijst | 2 | 3.000/min max | Beste voor incrementele synchronisatie - laagste kosten voor pollen |
| labels.lijst | 1 | 6.000/min max | Cacheer het resultaat - labels veranderen zelden |
| berichten.wijzigen | 5 | 1.200/min max | Gebruik batchModify voor bulklabelupdates |
| messages.attachments.ophalen | 5 | 1.200/min max | Haal bijlagen alleen op wanneer dit expliciet nodig is |
Pro tip: U kunt het velden= queryparameter voor gedeeltelijke antwoorden op elke methode. Het aanvragen van alleen de velden die uw toepassing nodig heeft, verlaagt de ruwe eenheidskosten niet, maar het verkleint de omvang van de antwoord-payload en de latentie aanzienlijk - de moeite waard wanneer u zich dicht bij de quotabeperkingen van de Gmail API bevindt. Test uw query's interactief met de Gmail OAuth Speeltuin voordat u naar productie gaat.
De verborgen limiet van 50 gelijktijdige verzoeken per postvak
Er is een limiet dat de meeste Gmail API-tutorials nooit vermelden, maar het is de oorzaak van mysterieuze 429-fouten in multi-threaded of asynchrone toepassingen: Gmail handhaaft een maximum van 50 gelijktijdige in-flight aanvragen per postbus. Deze limiet is volledig onafhankelijk van uw quota-eenhedenbudget. U kunt op 500 quota-eenheden van de 6.000 beschikbare zijn en toch een 429 ontvangen als u 51 verzoeken tegelijkertijd open heeft staan tegen de mailbox van dezelfde geauthenticeerde gebruiker.
Waarom dit ontwikkelaars verrast
Asynchrone frameworks zoals Node.js Promise.all() of Python asyncio.gather() maak het triviaal eenvoudig om 100+ gelijktijdige verzoeken te starten. Wanneer je een mailbox-synchronisatie verwerkt en uitwaaiert om 200 berichten tegelijkertijd op te halen namens een enkele geauthenticeerde gebruiker, Gmail ziet 200 open TCP-verbindingen tegen één mailbox en beperkt deze onmiddellijk. Het quotumdashboard in GCP zal voldoende resterende eenheden tonen - de limiet van 50 gelijktijdige verbindingen wordt niet als een quotummetriek weergegeven.
Wanneer het wordt geactiveerd
De limiet van 50 gelijktijdige verbindingen treedt op tijdens bulk mailbox synchronisatieoperaties: het ophalen van grote threads, het downloaden van bijlagen voor veel berichten tegelijkertijd, of het pagineren door grote labelaantallen terwijl ook resultaten gelijktijdig worden verwerkt. Elke code die meer dan 50 in-flight verzoeken naar dezelfde mailbox lanceert, zal deze limiet bereiken.
Hoe repareer ik het
Gebruik een concurrency limiter (semaphore) per geauthenticeerde gebruiker. In Node.js, bibliotheken zoals p-limiet goed werken. In Python, een asyncio.Semaphore(40) Met een veilige marge onder de 50 voorkomt dit de burst. Houd uw per-gebruiker concurrency op 40 of lager voor veiligheidsmarge.
// p-limit houdt gebruikersconcurrentie onder de 40importeer pLimiet van 'p-limiet';// Eén limiter-instantie per geauthenticeerde gebruiker (geïndexeerd op userId)const userLimieten = nieuw Kaart();functie getLimiter(gebruikersID) { als (!userLimiters.heeft(userId)) { Gebruikslimieten.zet(gebruikersId, pLimiet(40)); } return Gebruikslimieten.krijgen(gebruikersId);}// Wikkel elke Gmail API-aanroep in de limiter van de gebruikerasync function haalBericht(gmail, userId, messageId) { const limiet = getLimiter(gebruikersId); return limit(() => gmail.users.messages.krijgen({ userId: "mij, id: berichtId, velden 'id,threadId,payload.headers,snippet' }));}Fouten ontcijferen: 429 versus 403
Gmail API geeft twee verschillende HTTP-statuscodes terug voor quota- en toegangs problemen: 429 (Too Many Requests) en 403 (Forbidden). Binnen die twee codes zijn er vier verschillende redenen voor fouten, elk met een andere oorzaak en een andere oplossing. Deze door elkaar halen verspilt tijd aan het oplossen van problemen. Opmerking: OAuth-flowfouten zoals ongeldige_verlening zijn vernieuwingstokenfouten - deze zijn volledig gescheiden van de runtime limieten van de Gmail API.
| HTTP-code | Foutreden | Oorzaak | Repareer |
|---|---|---|---|
| 429 | rateLimitExceeded | Meer dan 1,2 miljoen quota-eenheden/min op GCP-projectniveau. Alle geauthenticeerde gebruikers in het project hebben collectief de limiet bereikt. | Exponentiële backoff + jitter. Wacht en probeer opnieuw. Lange termijn: opsplitsen in meerdere GCP-projecten of een quotumverhoging aanvragen. |
| 429 | GebruikerRateLimitOverschreden | Een enkele geauthenticeerde gebruiker heeft de limiet van 6.000 quotum-eenheden/min overschreden, OF heeft de limiet van 50 gelijktijdige verzoeken aan hun postvak overschreden. De meest voorkomende productie 429. | Per-gebruiker wachtrij met gelijktijdigheidslimiet. Pas het semaphore patroon toe (max 40 gelijktijdige). Voeg exponential backoff toe bij 429 retry. |
| 403 | dagelijkslimietOverschreden | Het GCP project verbruikte alle dagelijkse quotum eenheden van 80 miljoen vóór middernacht Pacific. Kan niet opnieuw worden geprobeerd totdat deze is gereset. Dit is een harde stop. | Wacht op de middernacht Pacific reset of een quotumverhoging aanvragen via de GCP console. Implementeer dagelijkse quota-budgettering per gebruiker in uw app. |
| 403 | quotaOverschreden | Een specifieke sub-quotum is overschreden. Kan ook duiden op het bereiken van de Gmail verzendquotum (500 e-mails/dag gratis, 2.000 Workspace) voor een specifiek afzenderadres. | Controleer welke quotum. Voor verzendquotum: wissel van verzendadres of wacht 24 uur. Voor andere subquota's: identificeer de specifieke metriek in het GCP-quotaoverzicht. |
Project-niveau limiet bereikt: 1,2 miljoen quota-eenheden/minuut voor alle gebruikers.
Repareren: Exponentiële backoff + jitter. Lange termijn: meerdere GCP-projecten of verzoek tot verhoging van quota.
Enkele gebruiker overschreed 6.000 eenheden/min OF 50 gelijktijdige verzoeken. Meest voorkomende 429.
Repareren: Per-gebruiker wachtrij + semafoor (max 40 gelijktijdig). Backoff-hertentative toevoegen.
Project heeft de dagelijkse quotum van 80 miljoen eenheden verbruikt. Stoppen tot middernacht Pacific.
Repareren: Wacht op reset of vraag quotumverhoging aan via de GCP-console.
Sub-quotum of Gmail verzendquotum (500/dag gratis, 2.000 Workspace) bereikt voor afzender.
Repareren: Controleer GCP-dashboard voor specifieke sub-limiet. Voor verzenden: adres wijzigen of 24 uur wachten.
ongeldige_verlening, toegang_geweigerden ongeldige_client komen uit de OAuth-tokenuitwisselingslaag, niet uit de Gmail API-quotasoorten en worden afzonderlijk behandeld in de Google OAuth foutenhandleiding. Als je een 401 Unauthorized ziet, is dat ook een authenticatieprobleem - controleer je OAuth-appverificatie status en of de vernieuwingstoken is verlopen. Productieklare afhandeling: exponentiële backoff + jitter
Exponentiële backoff is de enige juiste reactie op een 429 van de Gmail API. Direct opnieuw proberen maakt het probleem erger: je stapelt meer verzoeken op een reeds beperkt quotumvenster. Het toevoegen van willekeurige jitter voorkomt het "thundering herd"-probleem waarbij alle clients in een vloot exact op hetzelfde moment opnieuw proberen. Hieronder vindt u volledige, in productie geteste implementaties in Node.js en Python.
Eerste vertraging
Begin met 1.000 ms bij de eerste poging. Herhaal nooit onmiddellijk na een 429.
Exponentiële vermenigvuldiger
Dubbele vertraging elke poging: 1s, 2s, 4s, 8s, 16s. Limiteer op maximaal 32-64 seconden.
Willekeurige jitter
Voeg 0-500ms willekeurige jitter toe om gesynchroniseerde herhalingen van gelijktijdige werkprocessen te voorkomen.
// 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 - exponentiële backoff + jitter voor de limieten van de Gmail APIimporteer asyncio, willekeurigvan googleapiclient.fouten importeer HttpFoutasync def met_uitstel_gmail( fn, max_pogingen=5, initiële_vertraging=1.0, max_vertraging=32.0, trilling=0.5): "Wikkel elke Gmail API-aanroep in exponentiële backoff + willekeurige jitter. Overschrijdingen van Gmail API-limieten: rateLimitExceeded en userRateLimitExceeded. """ vertraging = initiële_vertraging voor poging in range(max_pogingen): proberen: return fn() # fn is een synchrone Gmail-clientaanroep uitzondering HttpFout als e: status = e.resp.status reden = e.error_details[0].krijgen('reden', '') als e.foutdetails anders '' # Opnieuw proberen bij 429; NIET opnieuw proberen bij dailyLimitExceeded hertry = status == 429 of reden in ( 'limietOverschreden', 'GebruikerslimietOverschreden' ) tenzij opnieuw te proberen of poging == max_pogingen - 1: verhogen wachten = min(vertraging + willekeurig.uniform(0, jolt), max_vertraging) wacht op asyncio.slaap(wacht) vertraging *= 2Strategieën om onder het maximum te blijven
Backoff lost het probleem op. Deze proactieve strategieën voorkomen dat u überhaupt tegen de limieten van de Gmail API-quota aanloopt. Ze zijn gerangschikt van de grootste naar de kleinste invloed op uw quotaverbruik. Door twee of drie van deze strategieën te combineren, kunt u uw kosten per eenheid bij typische, leesintensieve workloads met 80% verlagen.
Wachtrij per geauthenticeerde gebruiker
Onderhoud een aparte wachtrij per geverifieerde gebruiker. Meng nooit verzoeken van verschillende gebruikers in een gedeelde wachtrij. Dit isoleert blootstelling aan rate limits per gebruiker en maakt eerlijke wachtrijen mogelijk: als één gebruiker een 429 triggert, pauzeert alleen hun wachtrij - anderen gaan met volle snelheid verder. Gebruik Redis of een in-memory wachtrij met een token bucket per gebruiker.
Gebruik history.list in plaats van messages.list voor synchronisatie
Polling Berichtenlijst op een timer is de meest voorkomende fout bij het gebruik van de Gmail API. gebruikers.geschiedenis.lijst kosten slechts 2 eenheden (tegenover 5 voor messages.list) en geeft alleen de wijzigingen weer sinds je laatste synchronisatiepunt. Voor toepassingen met veel leesverkeer die grote mailboxen synchroniseren, kan deze optie alleen al het quota-verbruik met 60% verminderen. Sla de geschiedenisId van elke reactie met uw cursor. Koppel met Gmail Pushmeldingen (Pub/Sub) voor bijna realtime synchronisatie.
Batch API aanroepen
De Gmail API ondersteunt batchverzoeken: combineer tot 100 individuele verzoeken in één HTTP-aanroep. Elke subaanvraag telt nog steeds de normale eenheidskosten, maar je vermindert de TCP-overhead en de geconsumeerde "slots" voor snelheidsbeperking. Dit is bijzonder effectief voor berichten.ophalen operaties waarbij je veel berichten uit een sync delta moet ophalen. Controleer de Gmail batchgids voor implementatiedetails.
Gebruik gedeeltelijke reacties (fields=)
Elke Gmail API-methode ondersteunt de velden= parameter om alleen de eigenschappen op te vragen die je nodig hebt. Hoewel dit de kosten per verzoek niet verlaagt, vermindert het de omvang van het antwoord met 60-90% en verbetert het de responstijd. Voor een berichten.ophalen alleen retourneren id,threadId,payload.headers,snippet, de payload daalt van 40KB+ naar minder dan 2KB. Minder netwerk = snellere iteratie = meer ruimte voordat de dagelijkse quotlimiet van de Gmail API wordt bereikt.
Push vs. Poll: het juiste synchronisatiemodel
5 eenheden per poll + N x 5 eenheden om elke nieuwe boodschap op te halen. Voor 100 gebruikers x 30s interval = 1M eenheden/uur alleen aan polling overhead.
2 records per opvraging; geeft alleen wijzigingen weer sinds de laatste synchronisatie. 60% is goedkoper dan het opvragen van `messages.list` voor hetzelfde resultaat.
Geen quotakosten voor levering. Google stuurt een melding wanneer een mailbox verandert - je haalt alleen de delta op. Vereist een openbaar webhook-eindpunt. Ideaal voor bijna realtime toepassingen.
Schaalbaarheidsmogelijkheden voor meerdere tenants en een aanvraag voor een quotaverhoging
Zodra je verder gaat dan een handvol gekoppelde accounts, worden Gmail API-quota's een architecturale overweging. Dit gedeelte behandelt sharding van GCP-projecten voor grootschalige implementaties en het stapsgewijze proces om een verhoging van de Gmail API-quotum bij Google aan te vragen.
GCP project sharding
De limiet van 1,2 miljoen quotum-eenheden/min is per GCP-project. Als je 1.000 geauthenticeerde gebruikers hebt die allemaal actief synchroniseren, kun je deze verdelen over twee GCP-projecten om je effectieve capaciteit per project te verdubbelen. Elk project heeft zijn eigen OAuth-clientreferenties en toestemmingsscherm nodig. Gebruikers die aan project A zijn gekoppeld, kunnen de quotum van project B niet gebruiken. Dit is bijzonder nuttig voor e-mailsynchronisatiescenario's met een hoog volume waarbij het dagelijkse quotumlimiet van de Gmail API een zorg is. Controleer uw quotagebruik in de GCP-console om te weten wanneer sharding nodig is.
Quotaverhoging aanvragen
Google verleent op aanvraag quotaverhogingen, maar dit kost tijd (doorgaans 3-5 werkdagen voor de eerste beoordeling, tot 2 weken voor grote verhogingen). Dien in via de GCP Console: API's & Services > Gmail API > Quota's > "Meer quota aanvragen". Google vereist een gedetailleerde rechtvaardiging. Belangrijke punten om te vermelden: geschat aantal dagelijks actieve gebruikers, gemiddeld aantal verzoeken per gebruiker per dag, uitsplitsing per methode (berichten.verzenden vs Berichtenlijst enz.), en het productiegebruiksscenario. Vage aanvragen worden afgewezen. Geef concrete cijfers uit uw stagingtelemetrie.
Dagelijkse quota monitoren en budgetteren
Implementeer quotumbudget-tracking per geauthenticeerde gebruiker in uw eigen datalaag. Volg quotaEenhedenGebruikt voor elke gebruiker per dag. Wanneer een gebruiker de 70-80% van zijn dagelijkse budget per gebruiker nadert, schakel je voor die gebruiker voor de rest van de dag over van de modus ‘Active Sync’ naar de modus ‘Push-only’. Dit voorkomt dat één gebruiker met een hoog verbruik een onevenredig groot deel van de dagelijkse quota op projectniveau opgebruikt. De frequentie waarmee u quota per gebruiker toewijst, is een beslissing aan klantzijde in termen van uw applicatieontwerp.
Wat te vermelden in uw aanvraag voor quotaverhoging
Huidige gebruiksbasis: "We gebruiken momenteel X miljoen eenheden/dag bij Y actieve gebruikers."
Groeiprognose: "Over 6 maanden verwachten wij Z gebruikers, waarvoor circa W miljoen eenheden/dag nodig zullen zijn."
Gebruiksscenario: "Ons product leest Gmail om [CRM-synchronisatie / ATS-inbox / e-mailanalyses] mogelijk te maken. Gebruikers authentiseren individueel via OAuth."
Methode-uitsplitsing: ""Belangrijkste methoden: messages.list (40%), messages.get (35%), history.list (20%), messages.send (5%).""
Hoe Unipile Gmail-throttling beheert namens de geauthenticeerde gebruiker
Het bouwen van alle throttling-infrastructuur die in deze gids wordt beschreven - wachtrijen per gebruiker, semaforen, exponentiële backoff, dagelijkse quota-budgettering, GCP-projectbeheer - duurt weken en vereist doorlopend onderhoud. Unipile handelt dit af als onafhankelijke technische intermediair, zodat je team zich concentreert op productlogica, niet op quota-installaties. De toegang tot de Gmail API via Unipile is niet gelieerd aan, goedgekeurd door of gesponsord door Google.
Beheerde exponentiële backoff + jitter
Elke Gmail API-aanroep die wordt gedaan namens elke geauthenticeerde gebruiker gaat door de backoff-laag van Unipile. 429-fouten zijn transparant voor uw code: Unipile probeert automatisch opnieuw met volledige exponentiële backoff en jitter, waarbij alleen het uiteindelijke succes of een duidelijke fout na maximale pogingen wordt getoond.
Per-gebruiker wachtrijisolatie
Unipile handhaaft strikte isolatie per gebruiker. Een afgeremde geauthenticeerde gebruiker heeft nooit invloed op de doorvoer van een andere gebruiker. Elke gekoppeld account heeft zijn eigen wachtrij met individuele gelijktijdslimieten, wat zorgt voor een eerlijke toewijzing van bronnen aan uw gehele gebruikersbestand.
Verenigd model: Gmail + Outlook + IMAP
Dezelfde afknijplogica geldt uniform voor Gmail, Outlook (Microsoft 365 en Exchange Online), en IMAP. Uw applicatie gebruikt één gestandaardiseerde API, ongeacht welke e-mailprovider de geauthenticeerde gebruiker heeft gekoppeld. Geen provider-specifieke code voor snelheidslimieten om te onderhouden.
GDPR-conform, SOC2-georiënteerd
Gegevens geraadpleegd via Unipile zijn gebonden aan de sessie van de geauthenticeerde gebruiker Wie heeft de OAuth-toestemming verleend. Geen parallel archief, geen opslag van mailboxgegevens op lange termijn buiten de sessievereisten. GDPR en SOC2-naleving ingebouwd.
Met Unipile: geen vertraging, geen semaforen, geen quotabeheerUnipile handelt alle limieten van de Gmail API af als een onafhankelijke technische tussenpersoonimporteer UnipileClient van '@unipile/node-sdk';const klant = nieuw UnipileClient({ apiKey: process.env.UNIPILE_API_KEY, basisUrl: 'https://api3.unipile.com:13613'});// Berichten weergeven voor het gekoppelde Gmail-account van een geauthenticeerde gebruiker// Server-side afhandeling van throttling, backoff en per-gebruiker-isolatie door Unipileasync function haalRecenteE-mails(accountID) { const berichten = wacht op client.messaging.listBerichten({ account_id: accountId, // gekoppelde account van de geauthenticeerde gebruiker beperken: 25 }); return berichten;}// Werkt identiek voor Gmail, Outlook en IMAP-gekoppelde accounts// Zelfde code, geen provider-specifieke limietafhandelingGmail API Limieten voor aanvraagsnelheid - Veelgestelde vragen
Antwoorden op de meest gestelde vragen over Gmail API-limieten, quotum-eenheden, 429-fouten en het schalen van je integratie.
De Gmail API hanteert limieten die tegelijkertijd op drie niveaus worden afgedwongen. Op projectniveau: 1.200.000 quotum-eenheden per minuut gedeeld met alle gebruikers, en 80.000.000 quotum-eenheden per dag. Op gebruikersniveau: 6.000 quotum-eenheden per minuut per postvak. Er is ook een verborgen limiet van 50 gelijktijdige verzoeken per postbus die een 429 kan activeren, zelfs als u zich ver onder de quotumlimiet bevindt. Elke methode heeft een andere eenheidskost - berichten.verzenden kost 100 eenheden terwijl Berichtenlijst kost slechts 5.
Implementeren exponentiële backoff met jitterbegin bij 1.000 ms bij eerste poging, verdubbel bij elke poging, voeg 0-500 ms willekeurige jitter toe, beperk tot 32.000 ms. Probeer nooit onmiddellijk opnieuw. Voeg een concurrencybegrenzer bereik per geauthenticeerde gebruiker, waarbij in-flight verzoeken onder de 40 per postvak worden gehouden. Gebruik een per-gebruiker wachtrij zodat een gereguleerde gebruiker anderen niet beïnvloedt. Op langere termijn, wissel polling van Berichtenlijst (5 eenheden) naar geschiedenis.lijst (2 eenheden) en overweeg Gmail Pushmeldingen om polling volledig te elimineren.
De Gmail API dagelijkse quotum is 80.000.000 quotum-eenheden per GCP-project, reset om middernacht Pacific time. Deze limiet retourneert een 403 dagelijkseLimietOverschreden fout - in tegenstelling tot 429-fouten per minuut, kan dit niet opnieuw worden geprobeerd tot de dagelijkse reset. Om het te verhogen: GCP Console > APIs & Services > Gmail API > Quotas > Hogere quota aanvragen. Voeg huidig gebruik, projecties van groei en uw gebruiksscenario toe. Goedkeuring duurt doorgaans 3-5 werkdagen.
De Gmail De verzendquota bedraagt 500 e-mails per dag voor gratis Gmail-accounts en 2.000 e-mails per dag voor Google Workspace-accounts. Deze limiet geldt per afzenderadres en is gescheiden van het API-quotum van eenheidbudget. Elke berichten.verzenden een oproep kost ook 100 quota-eenheden, dus bij een limiet van 6.000 eenheden/min per gebruiker kun je maximaal 60 e-mails per minuut versturen voordat je de Gmail API-limiet per gebruiker bereikt - maar de dagelijkse limiet van 500/2.000 zal voor typische gebruiksscenario's waarschijnlijk eerder worden bereikt.
rateLimitExceeded betekent dat het hele GCP-project 1.200.000 quota-eenheden per minuut is gepasseerd - alle geauthenticeerde gebruikers samen. GebruikerRateLimitOverschreden betekent dat één gebruiker meer dan 6.000 quota-eenheden per minuut heeft overschreden of verstuurde meer dan 50 gelijktijdige verzoeken naar hun mailbox. In productie multi-tenant apps, GebruikerRateLimitOverschreden is veel gebruikelijker omdat individuele gebruikers onafhankelijk hun limieten kunnen bereiken, ongeacht de algemene projectlimieten. Beide retourneren HTTP 429 en beide reageren op exponentiële backoff.
Navigeer naar GCP Console > API's en services > Gmail API > Quota's en klik op "Hogere quota aanvragen". Uw aanvraag moet een concrete rechtvaardiging bevatten: huidige baseline dagelijks gebruik, projectie van gebruikersgroei over 6 maanden, beschrijving van hoe gebruikers individueel authenticeren via OAuth, en een uitsplitsing van API-methoden naar verhouding. Vage aanvragen worden geweigerd. Zorg er ook voor dat uw app OAuth geverifieerd - niet-geverifieerde apps zijn beperkt tot 100 testgebruikers, ongeacht het quotum. De beoordeling duurt doorgaans 3-5 werkdagen voor een eerste reactie.
berichten.verzenden kosten 100 quotum eenheden per oproep - de duurste methode van de Gmail API. Met de limiet per gebruiker van 6.000 eenheden/min kun je maximaal 60 e-mails per minuut per geauthenticeerde gebruiker verzenden. Ter vergelijking: berichten.ophalen kost 5 eenheden (1.200 oproepen/min), geschiedenis.lijst kost 2 eenheden (3.000 oproepen/min), en labels.lijst kosten 1 eenheid (6.000 oproepen/min). Overweeg voor grootschalige outreach of uw use case daadwerkelijk bellen vereist berichten.verzenden of of het efficiënter is om conceptversies te maken en in batches te verzenden.
Unipile heeft alleen toegang tot de gegevens die expliciet door uw toepassing worden aangevraagd, gebonden aan de sessie van de geauthenticeerde gebruiker wie OAuth-toestemming heeft verleend. Er is geen parallel archief, geen onafhankelijke opslag op lange termijn van mailboxgegevens buiten wat nodig is om de huidige API-aanvraag te verwerken. De gegevens van elke geauthenticeerde gebruiker zijn geïsoleerd: Unipile treedt op als een onafhankelijke technische tussenpersoon uitsluitend namens die specifieke gebruiker.
De frequentie en het volume van API-aanroepen die namens elke geauthenticeerde gebruiker worden gedaan, zijn een beslissing aan klantzijde. Unipile beheert de backoff- en wachtinfrastructuur, maar uw applicatie bepaalt hoe vaak u gegevens opvraagt. Unipile toont quota-fouten transparant en past retry-logica toe, maar de algehele aanroepfrequentie - inclusief hoeveel gebruikers tegelijkertijd synchroniseren en hoe vaak - blijft onder uw controle als ontwikkelaar die op Unipile bouwt.
Nee. Unipile is niet verbonden met, goedgekeurd door of gesponsord door Google. Unipile is een onafhankelijke technische tussenpersoon die Gmail API-aanroepen doet namens geauthenticeerde gebruikers die individueel OAuth-toestemming hebben verleend via hun eigen Google-accounts. Gmail is een handelsmerk van Google LLC. Alle Gmail API-quota's, snelheidslimieten en beleidsregels worden bepaald door Google en kunnen onafhankelijk van Unipile worden gewijzigd.
Vragen over Gmail API-limieten en Unipile-integratie? Ons team staat voor u klaar.
De Complete E-mail API Gids voor Ontwikkelaars
Gmail-limieten zijn één onderdeel van het plaatje van de e-mail API. De pillar guide behandelt Gmail-, Outlook- en IMAP-integratiepatronen van begin tot eind.
NL 
EN 
FR 
ES 
DE 
IT 
BR 
PL 
TR