限制和配額可避免 Google 基礎架構受到自動化程序的不當使用，以不當方式使用 Groups Migration API。來自 API 的過多要求可能是因錯字或系統效率不彰的系統而發出不必要的 API 呼叫。無論原因為何，只要特定來源的流量達到特定等級，就能維持 Google Workspace 系統的整體健康狀態。
API 要求失敗
萬一 API 要求失敗，應用程式會收到 HTTP 狀態碼回應。403 的 HTTP 狀態碼含有錯誤輸入的錯誤資訊，503 的 HTTP 狀態碼會包含錯誤資訊，指出已超出哪個 API 配額。這些回應可讓您的自訂應用程式偵測這些錯誤並採取適當行動。
具時效性的要求
如果要求必須在固定的時間內完成，請同時傳送要求，或是在 Java 或 C# 應用程式中使用多個執行緒。例如，按照月份或其他時間範圍細分要求。如果是執行緒，請嘗試從 10 個執行緒開始，每項要求一個執行緒。執行緒建議有取捨，對所有 API 情況來說都不適用。如果要求數量過大，就會發生配額錯誤。
以時間為準的錯誤
如果是基於時間限制的所有錯誤 (每個執行緒最多 N 個項目，尤其是 503 狀態碼錯誤)，建議您讓程式碼擷取例外狀況，並使用指數輪詢演算法，先等候一小段延遲，再重試失敗的呼叫。其中一個執行緒的 Groups Migration API 示例是等待 5 秒，然後重試失敗的呼叫。如果要求成功，請為其他執行緒重複此模式。如果第二個要求失敗，應用程式應依要求的頻率縮減資源，直到呼叫成功為止。例如，請將初始延遲時間提高為 10 秒，然後重新重試失敗的呼叫。此外，也要決定重試上限。] 例如，以不同的延遲時間重新傳送要求 5 至 7 次，應用程式會將錯誤傳回給使用者。
限制
| API 限制類別 | 限制 |
|---|---|
| 每秒查詢次數 (QPS) | 開發人員專案數量上限為每個帳戶每秒 10 次查詢 (QPS)。 |
配額
| API 配額類別 | 配額 |
|---|---|
| 每日的 API 要求數量上限 | 每日的 API 要求數量上限為 500,000 個。 |
| 封存 (郵件到期日) | 群組封存內容不會過期。封存功能會一直保留郵件，直到群組遭到刪除為止。電子郵件保留政策不會影響群組封存資料中的訊息。 |
| 郵件大小 | 郵件大小上限為 25 MB。這項限制包括郵件的中繼資料標頭、內文和所有附件。 |
其他限制類型
| 其他限制 | 限制與規範 |
|---|---|
| 內容類型格式 | 電子郵件必須採用標準 RFC 822 文字格式。
上傳已遷移的電子郵件時，要求的內容類型必須使用 Content-type: message/rfc822 標頭。 |
| API 回應中的資料格式 | 回應的資料格式為 JavaScript Object Notation (JSON)。 |
| 資料位置政策 | Groups Migration API 不支援基於合約規定，將資料儲存在特定地理或政治邊界的資料位置政策。如果您的帳戶需要資料位置，請勿使用 Groups Migration API。 |
| 平行插入訊息 | Groups Migration API 支援平行要求將電子郵件插入不同群組封存檔。不過，Groups Migration API 不支援同時將訊息插入同一個群組封存。這個版本的 Groups Migration API 不支援批次要求。 |
| 未經授權的要求 | Groups Migration API 不接受任何未經授權的要求。如未提供授權憑證，系統就會將要求視為未經授權的要求。詳情請參閱瞭解驗證與授權相關說明。 |