参考
正文速率限制
你能发多少请求、超了会怎样，以及其他值得了解的限制。
限制是为了保护所有共用这个服务的人。默认额度对正常使用很宽裕；就算碰到了，响应也会准确告诉你要等多久。
一览
| 限制 | 默认值 | 碰到时 |
|---|---|---|
每个账户的写请求（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 把结果带回来。
活动上线或大批量处理需要更高额度？请带上预计的用量联系我们。