频率限制

开放 API 按应用限制调用频率，防止失控循环拖垮平台。

两档额度

限流按「应用（appId）+ 接口档位」分别计数，两档互不影响：

接口	额度	说明
`POST /api/open/v1/tasks/submit`	120 / min	提交检测任务。默认 120 次/分钟。
`GET /api/open/v1/tasks/query\|online, /balance`	1200 / min	查询任务、在线报告、查询余额，三者合计计数。默认 1200 次/分钟（约 20 QPS，够 100 个在途任务每 5 秒轮询一次）。

以上额度为全平台统一设置，暂不支持按机构单独调整。若您的正常业务量确实会触及上限，请联系商务（hehaichun@ais.cn）说明用量，由平台评估后统一调整。

计数窗口

额度按分钟计算：每进入新的一分钟，计数从零重新开始。

额度按应用（appId）累计，与来源 IP 无关：同一应用从多台机器发起的请求共用同一份额度，规划并发时按应用整体计算。

超限时

超出额度的请求被直接拒绝，返回 HTTP 429，响应体为标准错误结构，错误码 1429

Plain

HTTP/1.1 429 Too Many Requests
Retry-After: 23
Content-Type: application/json;charset=UTF-8

{
  "code": 1429,
  "codeMsg": "请求过于频繁",
  "data": null
}

响应头 Retry-After 给出到本窗口结束的剩余秒数，按它退避后即可继续。这是保护性限制、不是终态错误：被拒的提交不会创建任务、不计费，重试即可。

接入建议

轮询查询务必写退避：任务在途时按秒级轮询即可，不要无间隔空转；能接回调的优先用回调，免轮询。
批量提交控制并发：把一批稿件摊到多分钟内提交，比瞬间打满再吃 429 更快拿到结果。
把 429 与 Retry-After 纳入客户端重试逻辑，不要把它当作普通失败无限重试——那会让限流窗口一直续下去。