在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
处理 429 响应而不丢失请求
429 状态码与 400 或 404 不是同一类失败。它表示请求格式正确，本来可以成功，但您在当前周期内的配额已经用完。
响应是什么样子
HTTP/1.1 429 Too Many Requests
X-Quota-Limit: 2500
X-Quota-Used: 2500
X-Quota-Free-Remaining: 0
X-Credits-Remaining: 0.00
X-Quota-Reset: 2026-09-22T00:00:00Z
{
"status": "error",
"error": {"code": "quota_exceeded", "message": "Daily quota exceeded"}
}不要丢弃请求
最常见的错误是将 429 与 400 同等对待，将其记录为失败后便不再理会。用户或您的脚本想要进行的底层查询仍然完全有效，只是需要稍后运行，或者使用不同的凭据运行。请将原始请求内容放入重试队列，而不是丢弃它。
读取重置时间
429 响应中的 X-Quota-Reset 响应头会准确告诉您每日配额何时重置。后台任务可以休眠到那个时间，然后继续处理队列，而不是反复轮询或猜测一个固定的重试间隔。
值得提前规划的第二种情况
429 并不总是意味着一整天的配额都已用完。如果 X-Key-IPs-Used 已达到 X-Key-IPs-Limit，某个密钥可能会被暂时拒绝从新的来源地址发起请求，即使来自其常用地址的请求仍然会成功。弄清楚到底是哪个响应头解释了这次 429，是配额耗尽还是 IP 名额限制，决定了如何解决：前一种情况需要等待重置，后一种情况则需要减少使用同一密钥的不同机器数量。
立即突破限制的两种方式
如果无法接受等待，有两个立即可用的选择：充值预付额度，每个请求 €0.0001；或者如果这是反复出现的情况而不是一次性的高峰，改用每月 €50 的 Unlimited 密钥。两者都能消除最初触发 429 的每日上限。
区分密钥限制与网络限制
由于免费配额由整个 IPv4 /24 或 IPv6 /48 网段共享，429 可能是由同一网络上其他地址的流量造成的，而不仅仅是您自己密钥的用量。在决定升级密钥是否真的能解决问题之前，请同时查看 X-Quota-Network-Used 和 X-Quota-Used，以区分这两种情况。
值得避免的错误
在收到 429 的那一刻就在紧凑的循环中立即重试失败的请求，只会在已经耗尽的配额上叠加更多失败的调用，而不会让您离成功的请求更近一步。请退避到响应头给出的重置时间，或者在代码路径不读取响应头时退避一个合理的固定延迟，而不是立刻再次猛烈调用端点。
将 429 视为“稍后再试”而不是“失败了”，能让队列在配额重置期间平稳运转，而不会丢失工作。整个 API 中各类错误结构的详细信息请参阅错误页面，当前的配额选项请参阅价格页面。