队列与限制
ReWords.AI API 的并发数、30 个任务的队列、提交和查询的速率限制、轮询方式、图片尺寸限制、Retry-After 以及幂等重试。
队列
- 每个账号最多同时处理 10 个任务。
- 它们后面最多可以有 30 个任务排队。任务排队时，
GET /edits/{id}会返回它的queue_position（排在它前面等待的任务数；运行中的任务不算在内，所以0表示下一个开始）和estimated_seconds（我们估计它完成的时间）。 - 已经有 30 个任务在排队时，
POST /edits返回503 queue_full，并带有Retry-After请求头。不会扣费。 - 任务离开队列后最多运行 10 分钟。排队等待的时间不算在内，所以队列满时，最坏情况下最后一个任务大约需要 30 分钟。 大多数任务 1–2 分钟完成，九成在 3 分钟内完成。
速率限制
每个账号（由它的所有密钥共享）在任意滚动的 60 秒内可以发出：
| 请求 | 上限 |
|---|---|
提交：POST /ocr、POST /edits | 30 |
查询：GET /edits/{id}、GET /account | 240 次查询 |
所有带有效密钥的请求都会计入，包括返回错误被拒绝的请求。缺少密钥或密钥无效的请求不计入任何账号。
超出时返回 429 rate_limited 和 Retry-After，它总是整数秒，表示窗口内最早的那个请求还要多久过期。
GET /account 会在 limits 里返回你当前的限制。企业账号可以有更高的限制。
轮询
- 任务处于
processing，或处于queued且queue_position为 0 时，每 5 秒轮询一次GET /edits/{id}。 - 任务排在队列更后面时，每 30 秒查一次。
estimated_seconds是预计完成的时间，不是查询间隔。
10 个任务处理中、30 个任务排队时，每分钟最多 190 次查询，在 240 次的限制以内。如果完全不想轮询，
可以传入 callback_url，接收 Webhook。
图片
- JPEG、PNG 或 WebP，最大 20 MB，最长边最多 8000 px。
- 可以用
image_url、image_base64、multipart 的image文件，或者之前 OCR 调用返回的image_id发送图片。 每个请求只能用其中一种。 - 每次编辑最多 20 处替换。
每种上传方式怎么编码、EXIF、透明背景和结果文件，见图片。
安全重试
每个 POST /edits 都带上 Idempotency-Key 请求头，这样在超时或网络出错后可以安全地重试。
24 小时内重复同一个 key，会返回 202 以及原任务的 id 和当前状态（它可能已经是 processing 或已完成），
而不会新建任务并扣费，即使请求体不同也是如此。
key 按账号区分，由该账号的所有 API 密钥共享。被拒绝的请求（任何 4xx 或 5xx）不会占用它的 key，
所以修正后可以用同一个 key 重新发送。