Skip to main content
/v1 API 实行两项相互独立的请求配额。只要其中任一配额耗尽,请求即会被拒绝。 每个密钥的配额会跟随该密钥,无论其在何处使用。每个 IP 的配额是未经身份验证流量的唯一配额,同时也是经过身份验证流量的第二道上限。
速率限制在身份验证之前执行,因此凭据无效或缺失的请求同样会计入来源配额。具体的数值配额由运营方配置,可能会发生变化;下文所述的响应约定是可以稳定依赖的接口。
请使用任一种 Basic 凭据形式进行身份验证,详见快速入门(apikey:secret 或 secret:)。 请将 BASE 设置为组织所在区域的主机,详见区域。

429 响应

当某项配额耗尽时,API 会返回 429 Too Many Requests,并附带 Retry-After 标头(以秒为单位)以及标准的 problem-details 响应正文:
429 Too Many Requests
该响应不会说明是哪一项配额已耗尽。请以相同方式处理每个 429:先等待,然后重试。

处理 429 响应

1

遵循 Retry-After

重试前,请至少等待 Retry-After 标头中指定的秒数。过早重试只会白白消耗那些注定被拒绝的请求所占用的配额。
2

重复失败时采用指数退避

如果重试再次被拒绝,请增大退避时间并加入随机抖动,以免并行的工作进程同步重试。切勿为了符合本地上限而缩短服务器给出的 Retry-After。如果服务器要求的等待时间超出了您的重试预算,请停止重试,并将该工作安排到稍后执行。
3

平滑请求速率

相比突发请求,请优先保持稳定的请求速率。对于批量读取,请使用最大分页大小(limit=500),以更少的请求覆盖整个集合,详见分页。当多个列表遍历并行运行时(例如 Power BI 表),请保持适度的并发,并遵循 Retry-After,以免临时出现的 429 导致整个刷新失败。
此示例仅对 GET 请求的 429 响应进行重试,最多尝试五次,每次尝试之间最多等待 60 秒。遇到其他错误时会立即停止。网络超时会向调用方传播。请根据您的工作负载配置超时和重试预算。requests 将读取超时解释为接收数据时的最长空闲时间,而非整体截止时间。 请从您的密钥管理器中加载 LIVING_SECURITY_API_KEY。运行此示例之前,请先安装 requests。调用 get_with_retry("/organization") 即可使用。
Python
请勿将此循环复制到写入操作中使用。写入后发生超时,可能意味着服务器在连接失败之前已提交该操作。只有当该操作的参考文档明确说明其具有幂等性时,才可重复执行写入,并且必须保持相同的密钥和载荷。否则,请先核对资源状态,再重新尝试。

建议的刷新计划

请根据您的密钥配额和分页大小来确定刷新频率。对大型集合进行完整的历史数据加载属于一次性成本;对于常规的稳态刷新,建议使用增量时间窗口,使每次运行都远低于配额。请务必显式设置 limit=500,因为默认值 25 会成倍增加请求数量。