Workday每秒支持的最大API调用次数是多少？有无限流解决方案？

这个是Workday公有云租户的通用默认限流规则，不是实施方故意设卡，几乎所有做多系统Workday集成的团队都踩过这个坑。早期版本Workday对超阈值请求直接丢弃不返回状态码，现在部分新租户会返回429状态码，但基础限流阈值没有变化。
我前后参与过4个中大型企业的Workday集成项目，以下是经过生产验证的可行方案：

• 搭建统一API网关做全局限流
  不要让每个对接系统各自控制调用频率，很容易出现多系统同时发请求总QPS超标的问题。在所有对接系统和Workday之间加一层统一的API入口，用令牌桶算法做全局流控，把总调用QPS控制在8-9之间，留10%-20%的冗余应对突发流量。网关层可以根据业务优先级给不同系统分配调用配额，避免非核心业务占满额度影响核心流程。如果暂时没有资源搭网关，就给每个对接系统单独配置限流规则，所有系统的阈值加总不要超过8。
• 批量接口+错峰调度压缩非实时请求量
  非实时类的同步任务（比如主数据定期同步、报表拉取、历史数据校对）全部调度到业务低峰期（通常是凌晨非工作时段）错峰执行，不要和工作时间的实时业务接口抢配额。另外优先用Workday的批量接口替代单条操作接口：比如单条调用Get_Workers接口一次只能查1个员工的信息，带分页参数的批量调用单次最多可以拉取999条数据，能直接把这类场景的请求量压到原来的几百分之一。
• 配置带指数退避的重试逻辑兜底
  针对可能被限流丢弃的请求，所有调用端都要加幂等校验+指数退避重试：首次请求失败后等待1秒重试，第二次等待2秒，第三次等待4秒，最多重试3次即可，不要做无间隔的死循环重试，不然只会堆更多无效请求占满配额。幂等校验一定要做，避免重试导致重复写入产生脏数据。
• 用事件订阅替代高频轮询
  很多集成场景一开始会用高频轮询的方式拉取Workday的数据变动，这部分通常占总请求量的70%以上。实际上Workday支持核心业务对象（员工、职位、组织架构、入职离职事件等）的Webhook订阅，数据发生变动时Workday会主动推送消息到你方指定的回调接口，完全不需要反复轮询发请求，能砍掉绝大多数无效调用。
• 特殊场景申请临时提额
  如果遇到历史数据批量迁移、季度/年度薪资核算这类短期需要高并发调用的场景，可以提前3-5个工作日通过对接的Workday客户经理提交临时提额申请，这类短期需求一般都会审批通过。但长期固定提升限流阈值的申请基本不会通过，不用在这上面浪费时间。

注意：不要尝试绕开限流做无管控的高并发调用，Workday的风控机制如果检测到账号/IP持续超阈值发送请求，会直接做封停处理，解封流程通常需要3-5个工作日，会严重影响正常业务运行。

内容的提问来源于stack exchange，提问作者Bryan Charlesworth