由於 Google Meet REST API 屬於共用服務，因此我們會套用配額與限制，確保所有使用者都能公平使用這項服務，並保護 Google Workspace 系統的整體效能。
如果超出配額，您通常會收到 429: Too many requests HTTP 狀態碼回應。如果發生這種情況，您應使用指數輪詢演算法，並於稍後再試一次。只要用量未超出每分鐘配額，每天可提出的要求數量就沒有上限。
下表詳細列出查詢限制：
| 配額 | |||||
|---|---|---|---|---|---|
| 讀取要求數 |
|
||||
| 寫入要求數 |
|
||||
|
減少寫入要求數
(用於 |
|
||||
解決以時間為基礎的配額錯誤
針對所有時間較長的錯誤 (每 X 分鐘最多 N 個要求)，建議您讓程式碼擷取例外狀況，並使用截斷的指數輪詢，確保裝置不會產生過多負載。
指數輪詢是網路應用程式的標準錯誤處理策略。 指數輪詢演算法會以指數方式逐漸增加要求之間的等待時間，並以指數方式重試要求，最多可達輪詢時間上限。如果要求還是失敗，請務必在要求成功前延長要求之間的延遲時間。
演算法範例
指數輪詢演算法會以指數方式重試要求，並增加重試之間的等待時間，最多可達輪詢時間上限。例如：
- 向 Google Meet API 提出要求。
- 如果要求失敗，請等待 1 +
random_number_milliseconds再重試要求。 - 如果要求失敗，請等待 2 +
random_number_milliseconds再重試要求。 - 如果要求失敗，請等待 4 +
random_number_milliseconds再重試要求。 - 依此類推，時間上限為
maximum_backoff。 - 繼續等待和重試，直到重試次數達上限，但不要增加每次重試之間的等待時間。
其中：
- 等待時間為
min(((2^n)+random_number_milliseconds), maximum_backoff)，每次疊代 (要求) 時n會增加 1。 random_number_milliseconds是小於或等於 1,000 的隨機毫秒數。這有助於避免在許多情況下，許多用戶端會因為某些情況同步處理並同時重試，避免在同步的 Wave 中傳送要求。每次重試要求後，random_number_milliseconds的值都會重新計算。maximum_backoff通常是 32 或 64 秒，應視用途而定。
用戶端可以在達到 maximum_backoff 時間後繼續重試。但接下來的重試工作就不需繼續增加輪詢時間。舉例來說，如果用戶端使用的 maximum_backoff 時間是 64 秒，接著達到這個值，用戶端就可以每 64 秒重試一次。之後應避免用戶端無限期重試。
重試與重試次數的等待時間取決於用途和網路狀況。
定價
Google Meet API 完全開放使用，您無須額外付費。超出配額要求限制不會產生額外費用，且帳戶也不會產生費用。
申請提高配額
視專案的資源用量而定，您可能會想要要求提高配額。服務帳戶的 API 呼叫視為單一帳戶。我們不保證一定能核准您提出的配額增加要求。大量提高配額可能需要較長時間才能通過核准。
並非所有專案的配額都相同。隨著您使用 Google Cloud 的情況逐漸增加，配額可能需要增加。如果您預期用量將大幅攀升，可以透過 Google Cloud 控制台的「配額」頁面主動提出配額調整要求。
如要進一步瞭解相關內容，請參閱下列資源：