為讓表單建立者進一步控管回覆者,我們推出了精細的回覆者控管功能。2026 年 1 月 31 日後透過 API 建立的表單,預設為未發布狀態。詳情請參閱「
Google 表單的 API 變更」。
用量限制
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
由於 Google 表單 API 是共用服務,我們會套用配額和限制,確保所有使用者都能公平使用,並保護 Google Workspace 系統的整體健康。
如果您超出配額,通常會收到 429: Too many requests
HTTP 狀態碼回應。如果發生這種情況,您應使用指數輪詢演算法,稍後再試一次。只要您維持在下方每分鐘配額內,每天可提出的要求次數就沒有限制。
注意:表單檢視器有其他限制。詳情請參閱「設定及接收推播通知」。
下表詳細列出要求限制:
配額 |
讀取要求數 |
每項專案每日 |
無限制 |
每項專案每分鐘 |
975 |
每位使用者每項專案每分鐘 |
390 |
|
耗用大量資源的讀取要求
(用於 forms.responses.list 要求)。
|
每項專案每日 |
無限制 |
每項專案每分鐘 |
450 |
每位使用者每項專案每分鐘 |
180 |
|
寫入要求數 |
每項專案每日 |
無限制 |
每項專案每分鐘 |
375 |
每位使用者每項專案每分鐘 |
150 |
|
解決以時間為準的配額錯誤
針對所有時間相關錯誤 (每 X 分鐘最多 N 個要求),建議您在程式碼中擷取例外狀況,並使用截斷的指數型延遲,確保裝置不會產生過多負載。
指數輪詢是網路應用程式的標準錯誤處理策略。指數輪詢演算法會以指數方式逐漸增加每次重試之間的等待時間,直到達到最大輪詢時間為止。如果要求仍無法成功,請務必讓要求之間的延遲時間隨著時間增加,直到要求成功為止。
演算法範例
指數輪詢演算法會以指數方式重試要求,並將每次重試之間的等待時間逐漸增加至最大輪詢時間,例如:
- 向 Google 表單 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 表單 API 完全免費。超出配額要求上限不會產生額外費用,也不會向您的帳戶收費。
申請提高配額
視專案的資源使用情形而定,您可能會想要求增加配額。服務帳戶的 API 呼叫會被視為使用單一帳戶。我們不保證一定能核准您提出的配額增加要求。不過如要增加大量配額,可能會需要更長的核准程序處理時間。
並非所有專案的配額都相同。隨著 Google Cloud 的使用量隨時間增加,您可能需要提高配額。如果您預期用量將大幅攀升,可以透過 Google Cloud 控制台的「配額」頁面主動要求調整配額。
如要進一步瞭解相關內容,請參閱下列資源:
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-04-09 (世界標準時間)。
[null,null,["上次更新時間:2025-04-09 (世界標準時間)。"],[],["The Google Forms API enforces quotas to ensure fair usage and system health. Exceeding quotas results in a `429` error, requiring the use of an exponential backoff algorithm for retries. There are per-day and per-minute limits for read, expensive read, and write requests, varying by project and user. Exponential backoff involves retrying failed requests with increasing wait times, capped at a maximum backoff time, then retrying at this constant wait time. Quotas can be increased via the Google Cloud console. The API is available at no additional cost.\n"],null,["# Usage limits\n\nAs the Google Forms 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\nIf you exceed a quota, you'll generally receive a `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\n**Note:** Form watches have additional limits. See\n[Set up and receive push notifications](/workspace/forms/api/guides/push-notifications#limits)\nfor more information.\n\nThe following table details the request limits:\n\n| Quotas ||\n|---------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Read requests | |---------------------------------|-----------| | Per day per project | Unlimited | | Per minute per project | 975 | | Per minute per user per project | 390 | |\n| Expensive read requests (Used for `forms.responses.list` requests.) | |---------------------------------|-----------| | Per day per project | Unlimited | | Per minute per project | 450 | | Per minute per user per project | 180 | |\n| Write requests | |---------------------------------|-----------| | Per day per project | Unlimited | | Per minute per project | 375 | | Per minute per user per project | 150 | |\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 Forms 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 Forms 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)"]]