Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Limity wykorzystania

Interfejs Gmail API podlega limitom wykorzystania, które ograniczają częstotliwość wywoływania metod interfejsu API. Limity są definiowane w jednostkach limitu, czyli abstrakcyjnych jednostkach miary reprezentujących wykorzystanie zasobów Gmaila.

Limity interfejsu Gmail API

Interfejs Gmail API wymusza 2 rodzaje limitów:

Na minutę na projekt: to liczba jednostek limitu, które projekt Google Cloud może wykorzystać w ciągu minuty.
Na minutę na użytkownika na projekt: to liczba jednostek limitu, które może wykorzystać dany użytkownik w Twoim projekcie w chmurze. Ten limit pomaga zapewnić sprawiedliwy podział wykorzystania wśród użytkowników.

W tabeli poniżej znajdziesz szczegółowe informacje o tych limitach:

Typ limitu wykorzystania	Limit
Na minutę na projekt	1 200 000 jednostek limitu
Za minutę na użytkownika na projekt	6000 jednostek limitu

Informacje o postępowaniu w przypadku błędów związanych z limitami znajdziesz w artykule Rozwiązywanie problemów.

Dzienny próg naliczania należności

Ten limit dzienny na projekt określa maksymalną liczbę jednostek limitu, które projekt Google Cloud może wykorzystać w ciągu 24 godzin, zanim zostaną naliczone opłaty.

Użycie poniżej tego progu nie powoduje naliczenia dodatkowych opłat, a Twoje konto Google Cloud nie jest obciążane. Google udostępni pełne informacje rozliczeniowe w 2026 r. z co najmniej 90-dniowym wyprzedzeniem przed wejściem w życie jakichkolwiek zmian.

Nie możesz poprosić o zwiększenie tego dziennego limitu.

W tabeli poniżej znajdziesz szczegółowe informacje o limicie:

Typ limitu progu	Limit
Na dzień na projekt	80 000 000 jednostek limitu

Więcej informacji znajdziesz w artykule Standaryzowany model Google Workspace dotyczący narzędzi i interfejsów API agentów.

Wykorzystanie limitu na metodę

Liczba jednostek limitu, które zużywa każde żądanie, zależy od wywoływanej metody i parametrów zapytania. W tabeli poniżej znajdziesz informacje o wykorzystaniu jednostek limitu na metodę:

Metoda	Jednostki przydziału
`drafts.create`	10
`drafts.delete`	10
`drafts.get`	20 (60, gdy `format` to `full`, `raw` lub `html`)
`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 (60, gdy `format` to `full`, `raw` lub `html`)
`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 (120, gdy `format` to `full`)
`threads.list`	10
`threads.modify`	10
`threads.trash`	20
`threads.untrash`	10
`watch`	100

W przypadku korzystania z interfejsu Gmail API obowiązuje też limit 500 odbiorców na e-maila.

Rozwiązywanie problemów z błędami dotyczącymi limitów czasowych

W przypadku wszystkich błędów związanych z czasem (maksymalnie N żądań na X minut) zalecamy, aby kod przechwytywał wyjątek i używał skróconego wzrastającego czasu do ponowienia, aby urządzenia nie generowały nadmiernego obciążenia.

Wzrastający czas do ponowienia to standardowa strategia obsługi błędów w aplikacjach sieciowych. Algorytm wzrastającego czasu do ponowienia ponawia żądania, stosując wykładniczo rosnące czasy oczekiwania między żądaniami, aż do osiągnięcia maksymalnego czasu do ponowienia. Jeśli żądania nadal nie będą się udawać, ważne jest, aby opóźnienia między nimi zwiększały się z czasem, aż żądanie zostanie zrealizowane.

Przykładowy algorytm

Algorytm wzrastającego czasu do ponowienia ponawia żądania wykładniczo, zwiększając czas oczekiwania między ponownymi próbami do maksymalnego czasu do ponowienia. Na przykład:

wysłać żądanie do interfejsu Gmail API,
Jeśli żądanie się nie powiedzie, poczekaj 1 + random_number_milliseconds i spróbuj ponownie.
Jeśli żądanie się nie powiedzie, odczekaj 2 + random_number_milliseconds i spróbuj ponownie.
Jeśli żądanie się nie powiedzie, odczekaj 4 + random_number_milliseconds i spróbuj ponownie.
I tak dalej, aż do maximum_backoff razu.
Kontynuuj oczekiwanie i ponawianie prób do maksymalnej liczby ponownych prób, ale nie zwiększaj czasu oczekiwania między próbami.

gdzie:

Czas oczekiwania wynosi min(((2^n)+random_number_milliseconds), maximum_backoff), przy czym n jest zwiększane o 1 przy każdej iteracji (żądaniu).
random_number_milliseconds to losowa liczba milisekund mniejsza lub równa 1000. Pomaga to uniknąć sytuacji, w których wiele klientów jest synchronizowanych przez jakąś sytuację i wszystkie ponawiają próbę jednocześnie, wysyłając żądania w zsynchronizowanych falach. Wartość random_number_milliseconds jest ponownie obliczana po każdym żądaniu ponowienia.
Wartość maximum_backoff to zwykle 32 lub 64 sekundy. Odpowiednia wartość zależy od przypadku użycia.

Klient może kontynuować próby po upływie czasu maximum_backoff. Po tym czasie nie trzeba już zwiększać czasu oczekiwania. Jeśli na przykład klient używa czasu maximum_backoff wynoszącego 64 sekundy, po osiągnięciu tej wartości może ponawiać próbę co 64 sekundy. W pewnym momencie należy uniemożliwić klientom ponawianie prób w nieskończoność.

Czas oczekiwania między próbami i liczba prób zależą od przypadku użycia i warunków sieciowych.

Ceny

Standardowe korzystanie z interfejsu Gmail API jest dostępne bez dodatkowych opłat. W późniejszym okresie 2026 r. planujemy wprowadzić opłaty za przekroczenie limitów żądań na koncie rozliczeniowym Google Cloud. Więcej informacji znajdziesz w artykule Standaryzowany model Google Workspace dotyczący narzędzi i interfejsów API agentów.

Poproś o zwiększenie limitu

W zależności od wykorzystania zasobów w projekcie możesz poprosić o dostosowanie limitu. Wywołania interfejsu API przez konto usługi są traktowane jako użycie jednego konta. Wysłanie wniosku o zwiększenie limitu nie gwarantuje jego zatwierdzenia. Zatwierdzenie próśb o dostosowanie limitu, które znacznie zwiększyłyby wartość limitu, może potrwać dłużej.

Nie wszystkie projekty mają takie same limity. W miarę jak z czasem będziesz coraz częściej korzystać z Google Cloud, może być konieczne zwiększenie wartości limitów. Jeśli spodziewasz się znacznego wzrostu wykorzystania, możesz z wyprzedzeniem poprosić o dostosowanie limitów na stronie Limity przydziału i limity systemu w konsoli Google Cloud.

Więcej informacji znajdziesz w tych materiałach:

Limity serwera MCP Gmaila

Serwer MCP Gmaila używa wskaźnika alokacji kosztów zapytania. W tabelach poniżej znajdziesz szczegółowe informacje o kosztach zapytań w przypadku poszczególnych metod serwera MCP Gmaila według sekcji:

Limity MCP Gmaila

Serwer egzekwuje 2 rodzaje limitów:

Na minutę na projekt: to koszt zapytania w projekcie w chmurze w ciągu 1 minuty.
Na minutę na użytkownika na projekt: to koszt zapytania w projekcie w chmurze przez 1 minutę, który może wykorzystać dowolny użytkownik.