מגבלות שימוש

החל מ-1 במאי 2026, מכסות השימוש ב-API הזה עודכנו. פרויקטים ב-Google Cloud שנעשה בהם שימוש כלשהו ב-API הזה בין נובמבר 2025 לאפריל 2026 ימשיכו לפעול במסגרת מכסות השימוש שהוגדרו להם בעבר. פרויקטים ב-Cloud שנוצרו ב-1 במאי 2026 או אחרי התאריך הזה כפופים למכסות החדשות של API.

מידע נוסף, כולל ציר זמן, זמין במאמר מודל סטנדרטי של Google Workspace לכלי סוכנים וממשקי API.

ההודעה המלאה זמינה במאמר Agent tools and security updates for Google Workspace developers (כלים לסוכנים ועדכוני אבטחה למפתחים של Google Workspace).

השימוש ב-Gmail API כפוף למגבלות שימוש שמגבילות את הקצב שבו אפשר לקרוא לשיטות של ה-API. המגבלות מוגדרות במונחים של יחידות מכסה, יחידת מידה מופשטת שמייצגת את השימוש במשאבי Gmail.

מכסות ב-Gmail API

יש שני סוגים של מכסות:

• לדקה לכל פרויקט בענן: מספר יחידות המכסה שפרויקט Google Cloud יכול להשתמש בהן בדקה אחת.

• לדקה לכל משתמש לכל פרויקט: זהו מספר יחידות המכסה שכל משתמש יכול להשתמש בהן בפרויקט בענן שלכם. המגבלה הזו נועדה לעזור לכם לוודא שהשימוש יתחלק באופן הוגן בין המשתמשים.

בטבלה הבאה מפורטות המגבלות האלה:

סוג מכסת השימוש	מגבלה
לדקה לכל פרויקט	‫1,200,000 יחידות מכסה
לדקה לכל משתמש לכל פרויקט	‫6,000 יחידות מכסת שימוש

מידע על טיפול בשגיאות שקשורות למגבלות זמין במאמר פתרון שגיאות.

סף החיוב היומי

המגבלה הזו לכל פרויקט ביום מגדירה את המספר המקסימלי של יחידות מכסה שפרויקט Google Cloud יכול להשתמש בהן בפרק זמן של 24 שעות לפני שמתחילים לחייב עליהן.

אם השימוש שלכם נמוך מהסף הזה, לא תחויבו בחשבון Google Cloud. פרטי החיוב המלאים ישותפו בהמשך בשנת 2026, לפחות 90 יום לפני ששינויים ייכנסו לתוקף.

אי אפשר לבקש להגדיל את מגבלת הסף היומית הזו.

בטבלה הבאה מפורטת המגבלה:

סוג מגבלת הסף	מגבלה
לכל פרויקט ביום	‫80,000,000 יחידות מכסה

מידע נוסף זמין במאמר בנושא מודל סטנדרטי של Google Workspace לכלי סוכנים וממשקי API.

ניצול המכסה לכל שיטה

מספר יחידות המכסה שנצרכות לכל בקשה משתנה בהתאם לשיטה שנקראת. בטבלה הבאה מפורט השימוש ביחידות המכסה לכל שיטה:

שיטה	יחידות מיכסה
drafts.create	10
drafts.delete	10
drafts.get	20
drafts.list	5
drafts.send	100
drafts.update	15
getProfile	1
history.list	2
labels.create	5
labels.delete	5
labels.get	1
labels.list	1
labels.update	5
messages.attachments.get	20
messages.batchDelete	50
messages.batchModify	50
messages.delete	10
messages.get	20
messages.import	25
messages.insert	25
messages.list	5
messages.modify	5
messages.send	100
messages.trash	20
messages.untrash	5
settings.delegates.create	100
settings.delegates.delete	5
settings.delegates.get	1
settings.delegates.list	1
settings.filters.create	5
settings.filters.delete	5
settings.filters.get	1
settings.filters.list	1
settings.forwardingAddresses.create	100
settings.forwardingAddresses.delete	5
settings.forwardingAddresses.get	1
settings.forwardingAddresses.list	1
settings.getAutoForwarding	1
settings.getImap	1
settings.getPop	1
settings.getVacation	1
settings.sendAs.create	100
settings.sendAs.delete	5
settings.sendAs.get	1
settings.sendAs.list	1
settings.sendAs.update	100
settings.sendAs.verify	100
settings.updateAutoForwarding	5
settings.updateImap	5
settings.updatePop	100
settings.updateVacation	5
stop	50
threads.delete	20
threads.get	40
threads.list	10
threads.modify	10
threads.trash	20
threads.untrash	10
watch	100

בנוסף, כשמשתמשים ב-Gmail API, יש מגבלה של 500 נמענים לכל הודעת אימייל.

פתרון שגיאות שקשורות למכסת זמן

לגבי כל השגיאות שמבוססות על זמן (מקסימום N בקשות לכל X דקות), מומלץ שהקוד יזהה את החריגה וישתמש בנסיגה אקספוננציאלית קטומה כדי לוודא שהמכשירים לא יוצרים עומס מוגזם.

השהיה מעריכית לפני ניסיון חוזר היא אסטרטגיה סטנדרטית לטיפול בשגיאות באפליקציות רשת. אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באמצעות הגדלה אקספוננציאלית של זמני ההמתנה בין הבקשות, עד למשך ההשהיה המקסימלי. אם הבקשות עדיין לא מצליחות, חשוב שההשהיות בין הבקשות יגדלו עם הזמן עד שהבקשה תצליח.

אלגוריתם לדוגמה

אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באופן אקספוננציאלי, ומגדיל את זמן ההמתנה בין הניסיונות החוזרים עד למשך ההשהיה המקסימלי. לדוגמה:

1. שליחת בקשה ל-Gmail API.
2. אם הבקשה נכשלת, צריך להמתין ‎1 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
3. אם הבקשה נכשלת, צריך להמתין ‎2 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
4. אם הבקשה נכשלת, צריך להמתין ‎4 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
5. וכך הלאה, עד maximum_backoff פעמים.
6. ממשיכים להמתין ולנסות שוב עד שמגיעים למספר מקסימלי מסוים של ניסיונות חוזרים, אבל לא מגדילים את תקופת ההמתנה בין הניסיונות החוזרים.

where:

• זמן ההמתנה הוא min(((2^n)+random_number_milliseconds), maximum_backoff), שבו n גדל ב-1 בכל איטרציה (בקשה).
• ‫random_number_milliseconds הוא מספר אקראי של אלפיות השנייה שקטן מ-1,000 או שווה לו. כך אפשר להימנע ממקרים שבהם הרבה לקוחות מסונכרנים בגלל מצב מסוים וכולם מנסים לשלוח בקשות בו-זמנית. הערך של random_number_milliseconds מחושב מחדש אחרי כל בקשה לניסיון חוזר.
• בדרך כלל, maximum_backoff הוא 32 או 64 שניות. הערך המתאים תלוי בתרחיש לדוגמה.

הלקוח יכול להמשיך לנסות שוב אחרי שהגיע לזמן maximum_backoff. ניסיונות חוזרים אחרי הנקודה הזו לא צריכים להמשיך להגדיל את זמן ההשהיה לפני ניסיון חוזר. לדוגמה, אם לקוח משתמש בזמן maximum_backoff של 64 שניות, אחרי שהוא מגיע לערך הזה הוא יכול לנסות שוב כל 64 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלה.

זמן ההמתנה בין ניסיונות חוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.

תמחור

כל השימוש הרגיל ב-Gmail API זמין ללא עלות נוספת. אנחנו מתכננים להתחיל לחייב את החשבון שלכם לחיוב ב-Google Cloud על חריגה ממגבלות הבקשות של המכסה בהמשך שנת 2026. מידע נוסף זמין במאמר בנושא מודל סטנדרטי של Google Workspace לכלי סוכנים וממשקי API.

שליחת בקשה להגדלת המכסה

יכול להיות שתרצו לבקש שינוי במכסות בהתאם לשימוש במשאבים בפרויקט. קריאות ל-API על ידי חשבון שירות נחשבות לשימוש בחשבון יחיד. הגשת בקשה להתאמת המכסה לא מבטיחה שהבקשה תאושר. יכול להיות שיחלפו יותר זמן עד לאישור בקשות להתאמת מכסה שיגרמו לעלייה משמעותית בערך המכסה.

המכסות לא זהות בכל הפרויקטים. ככל שהשימוש שלכם ב-Google Cloud יגדל עם הזמן, יכול להיות שתצטרכו להגדיל את ערכי המכסות. אם צפויה עלייה משמעותית בשימוש, אפשר לבקש התאמות של המכסות מראש בדף Quotas & System Limits (מכסות ומגבלות מערכת) במסוף Google Cloud.

מידע נוסף זמין במקורות המידע הבאים:

• מידע על שינוי מכסות
• איך רואים את השימוש במכסות ואת המגבלות
• איך מבקשים להגדיל את המכסות

מכסות של שרתי MCP ב-Gmail

שרת ה-MCP של Gmail משתמש במדד של הקצאת עלויות לשאילתות. בטבלאות הבאות מפורטת עלות השאילתה לכל שיטה של שרת Gmail MCP לפי קטע:

מכסות של Gmail MCP

יש שני סוגים של מכסות:

• לדקה לכל פרויקט בענן: זו העלות של השאילתה לפרויקט ב-Google Cloud למשך דקה אחת.

• לדקה לכל משתמש לכל פרויקט: זו העלות של שאילתה לפרויקט בענן ב-Google Cloud למשך דקה אחת שכל משתמש יכול להשתמש בה.

בטבלה הבאה מפורטות המכסות האלה:

סוג מכסת השימוש	עלות שאילתה
לדקה לכל פרויקט	1,200,000
לדקה לכל משתמש לכל פרויקט	6,000

מכסות של כלי MCP ב-Gmail

בטבלה הבאה מפורטות עלויות השאילתות לכל gmailmcp.googleapis.comערכת כלים:

נקודת קצה	כלי	עלות שאילתה
/mcp/v1	create_draft	10
	get_thread	40
	label_message	10
	label_thread	10
	list_drafts	5
	list_labels	1
	search_threads	10
	unlabel_message	10
	unlabel_thread	10

מידע נוסף זמין בחומר העזר בנושא Gmail MCP API.

נושאים קשורים

• בקשות באצווה
• טיפים לשיפור הביצועים
• מגבלות לשליחה וקבלה של אימיילים
• מגבלות שליחה שמוגדרות למשתמשי Gmail ב-Google Workspace