不用 Webhook，为大型批处理任务设置轮询

有些 API 会为大型批处理返回一个任务 ID，并要求您在其后台处理期间进行轮询或等待 Webhook。本 API 并非如此。每个批量请求，无论大小，都会在同一次调用中同步响应，这改变了您运行超大型任务时应有的思路。

与其提交一个庞大的数组然后等待，不如把大型任务拆分成固定大小的分块，每块几百到几千个条目，并将它们作为一系列普通的批量 POST 请求依次发送。由于每次调用都会立即返回结果，因此没有需要轮询的任务状态，只有下一个要发送的分块。

POST /v1/forward
Content-Type: application/json

["address 1", "address 2", "... up to a few hundred items"]

在这种设置中，最接近轮询的做法是在分块之间检查您自己的配额响应头，而不是检查任务状态。每个分块完成后读取 X-Quota-Free-Remaining 和 X-Credits-Remaining，如果即将用完每日免费配额而预付额度又不足以继续，就暂停或停止任务。

X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50

一个小脚本循环遍历各个分块，逐个发送，检查响应中的响应头，并根据看到的情况继续或暂停，这就是这里的大型批处理任务所需要的全部。没有单独的任务状态端点需要调用，因为您刚发送的分块已经包含了您请求的所有内容。

记录到目前为止已成功处理的分块索引，这样因配额重置或额度充值而暂停后，可以准确地从中断处恢复，而不是重新处理之前的分块、把请求花费两次。

无论哪种方式，费用都相同，整个任务中每个条目计一次请求。分块方式只改变您管理任务的方式，而不改变它总共使用的请求数。

把大型任务当作一系列普通的同步分块来处理，而不是去寻找这里并不存在的异步任务系统，可以让整件事保持简单。速率限制文档介绍了驱动这一模式的配额响应头。

在没有 webhook 的情况下为大型批量任务设置轮询