用量限制
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Google Vault API 是共用服務，因此我們設下配額和限制，確保所有使用者都能公平使用，並維護 Google Workspace 系統的整體健康狀態。
產品數量上限
您最多只能同時為貴機構執行 20 項匯出作業。
API 要求配額
每個機構每分鐘可讀取 600 個案件，包括透過 Vault API 和 vault.google.com 提出的要求，適用於所有專案和使用者。
下表列出每個專案每分鐘的要求數上限：
| 每項專案每分鐘的讀取要求數 |
| 匯出、案件和已儲存的查詢 |
120 |
| 保留 |
228 |
| 長期執行的作業 |
300 |
| 每項專案每分鐘的寫入要求數 |
| 匯出 |
20 |
| 保留 |
60 |
| 案件權限 |
30 |
| Matter |
60 |
| 已儲存的查詢 |
45 |
| 每項專案每分鐘的搜尋 (計數) 要求數 |
| 搜尋次數 |
20 |
依方法劃分的配額用量
要求使用的配額取決於呼叫的方法。
下表列出各方法的配額用量：
| 方法 |
配額費用 |
matters.close
matters.create
matters.delete
matters.reopen
matters.update
matters.undelete
|
1 個案件讀取
1 個案件寫入 |
matters.count |
1 個 |
matters.get |
已讀取 1 個案件 |
matters.list |
10 個案件讀取次數 |
matters.addPermissions
matters.removePermissions
|
1 個案件讀取
1 個案件寫入
1 個案件權限寫入 |
matters.exports.create |
1 次匯出讀取
10 次匯出寫入 |
matters.exports.delete |
1 次匯出寫入 |
matters.exports.get |
已讀取 1 個匯出項目 |
matters.exports.list |
5 次匯出讀取 |
matters.holds.addHeldAccounts
matters.holds.create
matters.holds.delete
matters.holds.removeHeldAccounts
matters.holds.update
|
1 項讀取案件
1 項寫入案件
1 項讀取保留
1 項寫入保留 |
matters.holds.list |
1 個案件已讀取
3 個案件已保留 |
matters.holds.accounts.create
matters.holds.accounts.delete
matters.holds.accounts.list
|
1 項讀取案件
1 項寫入案件
1 項讀取保留
1 項寫入保留 |
matters.savedQueries.create
matters.savedQueries.delete
|
1 項案件讀取
1 項案件寫入
1 項已儲存的查詢讀取
1 項已儲存的查詢寫入 |
matters.savedQueries.get |
1 個案件讀取
1 項已儲存的查詢讀取 |
matters.savedQueries.list |
1 項案件讀取
3 項已儲存的查詢讀取 |
operations.get |
1 項長時間執行的作業讀取 |
解決時間配額錯誤
如果超出每分鐘或每個機構的配額，通常會收到 429: Too many requests HTTP 狀態碼回應。
對於所有時間相關錯誤 (每 X 分鐘最多 N 個要求)，建議您的程式碼擷取例外狀況，並使用截斷指數輪詢，確保裝置不會產生過多負載。
指數輪詢是網路應用程式的標準錯誤處理策略。指數輪詢演算法會以指數方式重試要求，並將每次要求之間的等待時間逐漸增加至最大輪詢時間，如果要求仍未成功，請務必隨著時間增加要求之間的延遲時間，直到要求成功為止。
演算法範例
指數輪詢演算法會以指數方式重試要求，並將每次重試之間的等待時間逐漸增加至最大輪詢時間，例如：
- 對 Google Vault 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 的隨機毫秒數。這種設定有助於避免多個用戶端在特定情況下全部同步進行處理並同時重試，導致同步傳送每一波要求。random_number_milliseconds 的值會在每次重試要求後重新計算。maximum_backoff 通常是 32 或 64 秒，適合的值視用途而異。
用戶端達到 maximum_backoff 時間上限後，還是可以繼續重試。但接下來的重試工作就不需繼續增加輪詢時間。舉例來說，如果用戶端使用的 maximum_backoff 時間上限是 64 秒，達到這個值之後，用戶端就可以維持在每 64 秒重試一次的頻率。到了特定時間點後，用戶端應停止無限重試。
重試之間的等待時間和重試次數，應視用途及您的網路狀況而定。
申請提高配額
您可以依據專案的資源用量，要求調整配額。服務帳戶的 API 呼叫會視為使用單一帳戶。我們不保證一定能核准您提出的配額調整要求。如果配額調整要求會大幅提高配額值，可能需要較長時間才能通過核准。
並非所有專案的配額都相同。隨著您使用 Google Cloud 的時間越長，配額值可能需要增加。如果預期用量將大幅攀升，可以透過 Google Cloud 控制台的「配額」頁面主動要求調整配額。
如要進一步瞭解相關內容，請參閱下列資源：
定價
Google Workspace 客戶可免費使用 Google Vault API。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-29 (世界標準時間)。
[null,null,["上次更新時間：2025-08-29 (世界標準時間)。"],[],[],null,["# Usage limits\n\nAs the Google Vault API is a shared service, we apply quotas and limitations\nto make sure it's used fairly by all users and to protect the overall\nhealth of the Google Workspace system.\n\nProduct limits\n--------------\n\n\nYou can have no more than 20 exports in progress across your organization.\n\nAPI request quotas\n------------------\n\nEach organization is allowed 600 matter reads per minute, across all projects and users,\nincluding requests through the Vault API and vault.google.com.\n\nThe following tables list the per-minute per-project request limits:\n\n| Read requests per minute per project ||\n|---------------------------------|-----|\n| Export, matter, and saved query | 120 |\n| Hold | 228 |\n| Long-running operation | 300 |\n\n| Write requests per minute per project ||\n|--------------------|----|\n| Export | 20 |\n| Hold | 60 |\n| Matter permissions | 30 |\n| Matter | 60 |\n| Saved query | 45 |\n\n| Search (count) requests per minute per project ||\n|---------------|----|\n| Search counts | 20 |\n\nQuota usage by method\n---------------------\n\nThe quota used by a request depends on the method called.\nThe following table lists the per-method quota usage:\n\n| Method | Quota costs |\n|-----------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------|\n| `matters.close` `matters.create` `matters.delete` `matters.reopen` `matters.update` `matters.undelete` | 1 matter read 1 matter write |\n| `matters.count` | 1 count |\n| `matters.get` | 1 matter read |\n| `matters.list` | 10 matter reads |\n| `matters.addPermissions` `matters.removePermissions` | 1 matter read 1 matter write 1 matter permissions write |\n| `matters.exports.create` | 1 export read 10 export writes |\n| `matters.exports.delete` | 1 export write |\n| `matters.exports.get` | 1 export read |\n| `matters.exports.list` | 5 export reads |\n| `matters.holds.addHeldAccounts` `matters.holds.create` `matters.holds.delete` `matters.holds.removeHeldAccounts` `matters.holds.update` | 1 matter read 1 matter write 1 hold read 1 hold write |\n| `matters.holds.list` | 1 matter read 3 hold reads |\n| `matters.holds.accounts.create` `matters.holds.accounts.delete` `matters.holds.accounts.list` | 1 matter read 1 matter write 1 hold read 1 hold write |\n| `matters.savedQueries.create` `matters.savedQueries.delete` | 1 matter read 1 matter write 1 saved query read 1 saved query write |\n| `matters.savedQueries.get` | 1 matter read 1 saved query read |\n| `matters.savedQueries.list` | 1 matter read 3 saved query reads |\n| `operations.get` | 1 long-running operation read |\n\nResolve time-based quota errors\n-------------------------------\n\n\nIf you exceed a per-minute or per-organization quota, you usually get a\n`429: Too many requests` HTTP status code response.\n\n\nFor all time-based errors (maximum of N requests per X minutes), we recommend\nyour code catches the exception and uses a *truncated exponential backoff* to make sure your\ndevices don't generate excessive load.\n\n\nExponential backoff is a standard error handling strategy for network applications. An\nexponential backoff algorithm retries requests using exponentially increasing wait times\nbetween requests, up to a maximum backoff time. If requests are still unsuccessful, it's\nimportant that the delays between requests increase over time until the request is successful.\n\n### Example algorithm\n\n\nAn exponential backoff algorithm retries requests exponentially, increasing the wait time\nbetween retries up to a maximum backoff time. For example:\n\n1. Make a request to Google Vault API.\n2. If the request fails, wait 1 + `random_number_milliseconds` and retry the request.\n3. If the request fails, wait 2 + `random_number_milliseconds` and retry the request.\n4. If the request fails, wait 4 + `random_number_milliseconds` and retry the request.\n5. And so on, up to a `maximum_backoff` time.\n6. Continue waiting and retrying up to some maximum number of retries, but don't increase the wait period between retries.\n\n\nwhere:\n\n- The wait time is `min(((2^n)+random_number_milliseconds), maximum_backoff)`, with `n` incremented by 1 for each iteration (request).\n- `random_number_milliseconds` is a random number of milliseconds less than or equal to 1,000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of `random_number_milliseconds` is recalculated after each retry request.\n- `maximum_backoff` is typically 32 or 64 seconds. The appropriate value depends on the use case.\n\n\nThe client can continue retrying after it has reached the `maximum_backoff` time.\nRetries after this point don't need to continue increasing backoff time. For\nexample, if a client uses a `maximum_backoff` time of 64 seconds, then after reaching\nthis value, the client can retry every 64 seconds. At some point,\nclients should be prevented from retrying indefinitely.\n\n\nThe wait time between retries and the number of retries depend on your use case\nand network conditions.\n\nRequest a quota increase\n------------------------\n\n\nDepending on your project's resource usage, you might want to request a quota\nadjustment. API calls by a service account are considered to be using a\nsingle account. Applying for an adjusted quota doesn't guarantee approval. Quota adjustment\nrequests that would significantly increase the quota value can take longer to be approved.\n\n\nNot all projects have the same quotas. As you increasingly use Google Cloud over\ntime, your quota values might need to increase. If you expect a notable upcoming\nincrease in usage, you can proactively\n[request quota adjustments](https://cloud.google.com/docs/quota#requesting_higher_quota)\nfrom the [Quotas page](https://console.cloud.google.com/iam-admin/quotas)\nin the Google Cloud console.\n\nTo learn more, see the following resources:\n\n- [About quota adjustments](https://cloud.google.com/docs/quotas/overview#about_increase_requests)\n- [View your current quota usage and limits](https://cloud.google.com/docs/quota#viewing_your_quota_console)\n- [Request a higher quota limit](https://cloud.google.com/docs/quota#requesting_higher_quota)\n\nPricing\n-------\n\n\nAll use of Google Vault API is available at no additional cost to Google Workspace customers."]]
