用量限制
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
由於 Google Slides API 屬於共用服務，我們會套用配額與限制
確保所有使用者都能公平使用這些資源
確保 Google Workspace 系統健康狀態良好
如果超出配額，通常會收到
429: Too many requests
HTTP 狀態碼回應。如果發生這種情況，建議您使用
指數輪詢演算法，然後再試一次
規定的每分鐘配額不超過下列時間，
限制每日可提出的要求次數
下表詳細說明瞭要求的限制：
| 配額 |
| 讀取要求數 |
| 每項專案的每分鐘 |
3000 |
| 每項專案每位使用者的每分鐘 |
600 |
|
|
讀取要求成本過高
(用於 presentations.pages.getThumbnail 要求)。
|
| 每項專案的每分鐘 |
300 |
| 每項專案每位使用者的每分鐘 |
60 |
|
| 寫入要求數 |
| 每項專案的每分鐘 |
600 |
| 每項專案每位使用者的每分鐘 |
60 |
|
解決以時間為依據的配額錯誤
針對所有以時間為基礎的錯誤 (每個 X 分鐘最多 N 個要求)，我們建議您
程式碼會擷取例外狀況，並使用部分指數輪詢確保
裝置不會產生過多的負載
指數輪詢是網路應用程式的標準錯誤處理策略。一個
指數輪詢演算法會以指數方式延長等待時間
輪詢時間上限。如果要求依然失敗
請務必確認要求之間的延遲時間會隨著時間增加，直到要求成功為止。
演算法範例
指數輪詢演算法會以指數方式重試要求，進而增加等待時間
延遲時間上限。例如：
- 向 Google Slides 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 秒重試一次。在某些情況下
用戶端應避免無限期重試。
重試與重試次數的等待時間取決於您的用途
以及網路狀況
定價
您不必額外付費即可使用 Google Slides API。超出配額
要求限制並不會產生額外費用，而且帳戶也不會產生費用。
申請提高配額
視專案的資源用量而定，您可能會想要申請配額
。由服務帳戶發出的 API 呼叫被視為使用
單一帳戶。我們不保證一定能核准您申請更多配額。大
提高配額的申請作業可能需要較長的時間才能通過核准。
並非所有專案的配額都相同。隨著您越來越常使用 Google Cloud
則可能需要提高配額您意料之中
並由系統主動提供
要求調整配額
前往「配額」頁面
也能前往 Google Cloud 控制台
如要進一步瞭解相關內容，請參閱下列資源：
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-03-21 (世界標準時間)。
[null,null,["上次更新時間：2025-03-21 (世界標準時間)。"],[],[],null,["# Usage limits\n\nAs the Google Slides 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\n\nIf you exceed a quota, you'll generally receive a\n`429: Too many requests`\nHTTP status code response. If this happens, you should use an\n[exponential backoff algorithm](#exponential) and try again\nlater. Provided you stay within the per-minute quotas below, there's no\nlimit to the number of requests you can make per day.\n\nThe following table details the request limits:\n\n| Quotas ||\n|---------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------|\n| Read requests | |---------------------------------|------| | Per minute per project | 3000 | | Per minute per user per project | 600 | |\n| Expensive read requests (Used for `presentations.pages.getThumbnail` requests.) | |---------------------------------|-----| | Per minute per project | 300 | | Per minute per user per project | 60 | |\n| Write requests | |---------------------------------|-----| | Per minute per project | 600 | | Per minute per user per project | 60 | |\n\nResolve time-based quota errors\n-------------------------------\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 Slides 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\nPricing\n-------\n\n\nAll use of the Google Slides API is available at no additional cost. Exceeding the quota\nrequest limits doesn't incur extra charges and your account is not billed.\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)"]]
