/v1 API 实行两项相互独立的请求配额。只要其中任一配额耗尽,请求即会被拒绝。
每个密钥的配额会跟随该密钥,无论其在何处使用。每个 IP 的配额是未经身份验证流量的唯一配额,同时也是经过身份验证流量的第二道上限。
速率限制在身份验证之前执行,因此凭据无效或缺失的请求同样会计入来源配额。具体的数值配额由运营方配置,可能会发生变化;下文所述的响应约定是可以稳定依赖的接口。
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 导致整个刷新失败。429 响应进行重试,最多尝试五次,每次尝试之间最多等待 60 秒。遇到其他错误时会立即停止。网络超时会向调用方传播。请根据您的工作负载配置超时和重试预算。requests 将读取超时解释为接收数据时的最长空闲时间,而非整体截止时间。
请从您的密钥管理器中加载 LIVING_SECURITY_API_KEY。运行此示例之前,请先安装 requests。调用 get_with_retry("/organization") 即可使用。
Python
建议的刷新计划
请根据您的密钥配额和分页大小来确定刷新频率。对大型集合进行完整的历史数据加载属于一次性成本;对于常规的稳态刷新,建议使用增量时间窗口,使每次运行都远低于配额。请务必显式设置limit=500,因为默认值 25 会成倍增加请求数量。
