參考
主要內容速率限制
你能送出多少請求、超過會怎樣，以及其他值得了解的限制。
限制是為了保護所有共用這項服務的人。預設額度對一般使用相當寬裕；就算碰到了，回應也會確切告訴你要等多久。
一覽
| 限制 | 預設值 | 碰到時 |
|---|---|---|
每個帳戶的寫入請求（createTask、retry、上傳 …） | 每 10 秒 1,000 次 | 429，附 Retry-After |
每個帳戶的讀取請求（recordInfo、models、jobs、quote …） | 每 10 秒 1,000 次 | 429，附 Retry-After |
| 上傳票證 | 每 10 秒 1,000 次，另計於寫入請求之上 | 429，附 Retry-After |
用量報表（/api/v1/usage） | 每個帳戶每分鐘 30 次 | 429，附 Retry-After |
| 素材庫 | 每分鐘 60 次讀取、30 次儲存，另有每日新增數量上限 | 429，附 Retry-After |
| 驗證金鑰之前的任何請求 | 每個網段每分鐘 6,000 次 | 429 |
| 請求內容 | JSON 不超過 2 MiB | 413 |
| 餘額 | 你帳戶裡有多少 | 40201 |
| 金鑰消費上限 | 沒設定就沒有 | 40202 |
限制以帳戶計算，不是以金鑰計算——多建幾把金鑰並不會提高額度。
回應標頭
| 標頭 | 意思 |
|---|---|
X-RateLimit-Limit | 目前時間區間的額度 |
X-RateLimit-Remaining | 區間內剩餘次數——成功的回應也會帶，方便你提早放慢 |
Retry-After | 出現在 429：重試前要等待的秒數 |
上方數字是預設值，可能調整；請以回應標頭為準，不要寫死在程式裡。
碰到限制時的樣子
{ "code": 429, "msg": "Too many requests. Retry in a moment", "request_id": "req_…" }超過限制的請求會立刻被拒絕，不會排隊，也不收費。
如何處理
- 至少等
Retry-After秒再重試。加上一點隨機延遲，避免一批用戶端同時湧回。 - 重試
createTask時，請帶同一個Idempotency-Key（見冪等）。 - 輪詢要溫和：圖片幾秒一次，影片 10–15 秒一次。更好的做法是使用 Webhook——完全不占請求次數。
同時執行大量任務
速率限制管的是你送出請求的速度，不是同時執行的任務數。你可以讓很多任務同時進行，長影片只是比較久。如果要一次啟動成千上萬個任務，請分散送出，讓 Webhook 把結果帶回來。
活動上線或大量處理需要更高額度？請附上預估用量聯絡我們。