用量限制

Google Chat API 屬於共用服務，因此我們對以下項目設有配額與限制： 確保所有使用者都能公平地使用這項工具 效能優異

如果超出配額，您將收到 429: Too many requests HTTP 狀態碼回應。檢查 Chat 的其他頻率限制 後端也可能會產生相同的錯誤回應。如果發生這類錯誤， 應使用 指數輪詢演算法 然後再試一次。只要不超過 下表沒有要求數量限制 每天。

Chat API 方法適用兩種配額類型：每個空間和每項專案

每個空間配額

個別空間配額會限制特定空間中的查詢頻率， 在該聊天室中，呼叫下列清單的所有 Chat 擴充應用程式 每種配額的 Chat API 方法。

下表詳細列出每個空間的查詢限制：

每個空間配額	Chat API 方法	限制 (每 60 秒，與聊天室中所有 Chat 擴充應用程式 共用)
每分鐘讀取數	media.download spaces.get spaces.members.get spaces.members.list spaces.messages.get spaces.messages.list spaces.messages.attachments.get spaces.messages.reactions.list	900
每分鐘寫入數	media.upload spaces.delete spaces.patch spaces.messages.create (也適用於連入的 Webhook) spaces.messages.delete spaces.messages.patch spaces.messages.reactions.create spaces.messages.reactions.delete	60

每項專案的配額

每項專案配額會限制 Google Cloud 專案的查詢頻率 因此適用於呼叫指定 每種配額的 Chat API 方法。

下表詳細說明每個專案的查詢限制。你也可以 請參閱「配額」頁面的這些限制。

每項專案的配額	Chat API 方法	限制 (每 60 秒)
每分鐘訊息寫入數	spaces.messages.create spaces.messages.patch spaces.messages.delete	3000
每分鐘訊息讀取數	spaces.messages.get spaces.messages.list	3000
每分鐘成員資格寫入	spaces.members.create spaces.members.delete	300
每分鐘成員資格讀取數	spaces.members.get spaces.members.list	3000
每分鐘空間寫入作業數	spaces.setup spaces.create spaces.patch spaces.delete	60
每分鐘空間讀取數	spaces.get spaces.list spaces.findDirectMessage	3000
每分鐘連結寫入數	media.upload	600
每分鐘連結讀取數	spaces.messages.attachments.get media.download	3000
每分鐘回應寫入數	spaces.messages.reactions.create spaces.messages.reactions.delete	600
每分鐘的回應讀取數	spaces.messages.reactions.list	3000

額外用量限制

建立「GROUP_CHAT」類型的聊天室時設有其他配額限制 或 SPACE (使用 spaces.create 或 spaces.setup 方法)。 每分鐘建立不到 35 個聊天室，每個聊天室最多可建立 210 個空格 共計 1 個小時的內容DIRECT_MESSAGE 類型的聊天室不適用這些規則 額外增加配額限制

凡是指定相同空間的 API 的每秒大型查詢 (QPS) 都可觸發 網站上未顯示的其他內部限制 頁面。

解決以時間為依據的配額錯誤

針對所有以時間為基礎的錯誤 (每個 X 分鐘最多 N 個要求)，我們建議您 程式碼會擷取例外狀況，並使用部分指數輪詢確保 裝置不會產生過多的負載

指數輪詢是網路應用程式的標準錯誤處理策略。一個 指數輪詢演算法會以指數方式延長等待時間 輪詢時間上限。如果要求依然失敗 請務必確認要求之間的延遲時間會隨著時間增加，直到要求成功為止。

演算法範例

指數輪詢演算法會以指數方式重試要求，進而增加等待時間 延遲時間上限。例如：

1. 向 Google Chat API 提出要求。
2. 如果要求失敗，請等待 1 + random_number_milliseconds，然後再試一次 要求。
3. 如果要求失敗，請等待 2 + random_number_milliseconds，然後再試一次 要求。
4. 如果要求失敗，請等待 4 + random_number_milliseconds，然後再試一次 要求。
5. 依此類推，時間上限為 maximum_backoff。
6. 繼續等待及重試，直到重試次數達特定上限，但不要增加等待時間 延遲時間

其中：

• 等待時間：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 秒重試一次。在某些情況下 用戶端應避免無限期重試。

重試與重試次數的等待時間取決於您的用途 以及網路狀況

要求提高每項專案的配額

視專案的資源用量而定，您可能會想要申請配額 。由服務帳戶發出的 API 呼叫被視為使用 單一帳戶。我們不保證一定能核准您申請更多配額。大 提高配額的申請作業可能需要較長的時間才能通過核准。

並非所有專案的配額都相同。隨著您越來越常使用 Google Cloud 則可能需要提高配額您意料之中 並由系統主動提供 要求調整配額 前往「配額」頁面 也能前往 Google Cloud 控制台

如要進一步瞭解相關內容，請參閱下列資源：

• 關於配額提高要求
• 查看目前的配額用量和限制
• 要求提高配額限制