限制和配額可避免自動化程序以不當方式使用 Reports API，進而保護 Google 基礎架構。API 提出過多要求可能是因為無害的錯字，也可能是因為系統設計效率不彰，導致不必要的 API 呼叫。無論原因為何，一旦特定來源的流量達到一定程度，就必須封鎖該來源的流量，才能確保 Google Workspace 系統的整體健康狀態。確保一位開發人員的行為不會對廣大社群造成負面影響。
萬一 API 要求失敗，您會收到 HTTP 狀態碼回應。狀態碼 403 含有輸入內容不正確的錯誤資訊，而狀態碼 503 則含有錯誤資訊，指出超出哪些 API 配額。自訂應用程式可透過這些回應偵測錯誤，並採取適當行動。
如果要求必須在固定時間內完成，請平行傳送要求，或在 Java 或 C# 應用程式中使用多個執行緒。舉例來說，平行要求是指要求來自不同使用者的少量電子郵件，而不是同時新增或移除來自同一位使用者的多封電子郵件。如果是討論串，請先嘗試 10 個討論串，每個討論串對應一封使用者電子郵件。請注意，執行緒建議有其缺點，不適用於所有 API 情況。如果要求數量過高，就會發生配額錯誤。
對於所有以時間為準的錯誤 (每個執行緒每 N 秒最多 N 個項目)，尤其是 503 狀態碼錯誤，建議您的程式碼擷取例外狀況，並使用指數輪詢演算法等待一小段時間，然後重試失敗的呼叫。以一個執行緒為例，如果 Reports API 呼叫失敗，請等待 5 秒後重試。如果要求成功，請對其他執行緒重複這個模式。如果第二次要求未成功，應用程式應減少要求頻率，直到呼叫成功為止。舉例來說，將初始 5 秒延遲時間增加至 10 秒，然後再次重試失敗的呼叫。此外，請決定重試次數上限。舉例來說，應用程式可以先重試要求 5 到 7 次，每次的延遲時間都不同，再向使用者傳回錯誤。
限制
| API 限制類別 | 限制 |
|---|---|
| 回報每秒查詢次數和每秒查詢次數上限 | API 會限制 Google Cloud 專案的要求數量。Google Cloud 控制台預設值為每位使用者每分鐘每個 Google Cloud 專案 2,400 個查詢。如要提高這項限制，請前往 Google Cloud 專案的 Admin SDK API 配額頁面。
如果超過這些限制，伺服器會傳回 HTTP 503 狀態碼。重試要求時，請使用指數輪詢演算法。 |
activities.list 的其他限制 |
activities.list API 的額外限制為每分鐘 250 個篩選器查詢 (每小時 15,000 個篩選器查詢)。
篩選查詢是 API 要求，其中至少包含下列其中一個查詢參數：
|
| API 配額類別 | 配額 |
| maxResults | API 回應中每頁列出的記錄數為 0 到 1000 筆。預設值為 1000 筆記錄。 |
其他類型的限制
| 其他類型的限制 | 限制與規範 |
|---|---|
| 資料格式 (預設) | 預設資料格式為 JSON。API 也支援 Atom 格式。 |
| 未授權要求 | Google 不允許未經授權的要求存取 API。如果未提供授權權杖，系統會將要求視為未經授權。詳情請參閱「授權要求」。 |
| 警告訊息 |
|
activities.list 的最佳做法
activities.list 方法應適用於稽核調查。
為獲得最佳效能，要求應使用 startTime 和 endTime 參數指定時間範圍。時間範圍越窄，回應時間就越短。
這個方法不適用於大量擷取稽核記錄。如果經常超出 activities.list 篩選器要求配額，請考慮下列選項：
- 設定將 Google Workspace 記錄匯出至 BigQuery，並使用 BigQuery 強大的查詢 API 擷取及分析所需資料，完全不受 API 配額限制。
- 請使用含時間範圍的非篩選器要求，並執行用戶端篩選 (也就是在應用程式中執行篩選邏輯)，而非使用篩選器要求。這樣一來，您就能突破每分鐘 250 個篩選查詢的限制，但仍須遵守每位使用者每分鐘每個 Google Cloud 專案 2,400 個查詢的限制。