经营分析
Ozon 报 429 限流怎么办?先搞清楚是谁在占配额
429 的字面意思是「你的请求太密了」。多数人的第一反应是重试,或者怀疑 API Key 坏了去重新绑定——这两个动作都没用,而且第二个还会让问题看起来更严重。
关键在于:Ozon 的速率限制按卖家账号统计,不分是谁发的请求。只要有任何工具在用你这个 Key,它消耗的都是同一份配额。你这边一个请求没发,配额也可能已经被别处用光了。
所以遇到 429,第一件事不是重试,是搞清楚这个 Key 还在哪些地方被用着。下面讲清限流的判断方法、为什么短间隔重试会适得其反,以及怎么从根本上避免。
三步判断
- 1看报错文案里有没有 429 或 rate limit——有就是限流,和商品资料无关。
- 2看是不是所有 API 操作都在失败(上架、库存、订单同步)。只有一个失败通常不是限流。
- 3去 Ozon 后台生成一个新 API Key,只填到一处用。新 Key 正常 = 旧 Key 在别处被占;新 Key 也不行 = 账号级限制,找 Ozon 客服。
别反复删了重新绑定
绑定时系统要调 Ozon 接口验证 Key,限流期间这个验证同样会失败。这会让人误以为 Key 坏了,于是反复删了重绑——每次都失败,但原因始终是限流,不是 Key。
怎么确认是限流而不是别的问题
限流有一个很好认的特征:所有走 API 的操作会同时失灵。
上架、改库存、改价格、订单同步——这些功能走的是同一份配额,配额用光时它们一起坏。反过来,如果只有某一个功能报错、别的都正常,那基本可以排除限流,该去查那个功能本身(权限不足、资料不合法、类目问题)。
看报错文案
限流的报错里会明确出现 429 或 rate limit 字样。如果报错说的是权限、字段、类目,那是另一类问题,和请求频率无关——这两类问题的解决方向完全相反,先分清再动手。
为什么短间隔重试会适得其反
限流是速率问题:平台限制的是「每秒能发多少个请求」。这意味着退避时间不够长的重试,只会落在同一个限流窗口里,再撞一次墙。
更糟的是,失败的重试本身也算请求。5 秒后重试一次、又失败、再重试……你实际是在用重试请求继续消耗那份已经不够用的配额,把限流状态维持得更久。
正确的退避方式
间隔要成倍拉长(比如 1 秒、2 秒、4 秒、8 秒),而不是固定 5 秒反复试。真的很急的话,等几分钟再操作,比连续重试快得多。
根本解法:一个 Key 只给一处用
上面所有的排查,最终都指向同一个结论:同一个 API Key 被多个工具共用,是 429 最常见的根源。
问题在于 Ozon 后台看不到 Key 的调用来源,你无法直接知道谁在用。所以最干净的做法不是排查,是重建:生成一个新 Key,只填到一个地方,把旧 Key 停掉。这既解决了当前问题,也让以后出问题时能一眼定位。
回想一下这个 Key 有没有给过:代运营团队、第三方 ERP、自己写的脚本、其他采集软件。这些都是常见的「忘了还在跑」的来源。
新 Key 也 429 怎么办
说明限制在账号层面,不是 Key 被共用。这时候需要联系 Ozon 客服了解具体原因——可能是账号被临时限速,自己排查不出来。
用熊掌ERP 试试这个功能
一个工作台完成 Ozon 采集、采购、发货,支持最多 20 个店铺,提供 ¥0 免费体验版。
其他常见问题
正文没有覆盖到的零碎疑问,集中放在这里。
重新生成 API Key 能解决 429 吗?
能,而且这是最快的判断方法。在 Ozon 后台生成一个新 Key,只填到一个地方用。如果新 Key 立刻正常,说明旧 Key 在别处被占用;如果新 Key 也 429,说明是账号级的限制,需要联系 Ozon 客服了解原因。
429 时重试有用吗?
间隔太短的重试没用,反而可能延长限流。限流是速率问题,退避不够长就永远撞同一堵墙。正确做法是拉长间隔(至少十几秒起),或者干脆等几分钟。
怎么知道 API Key 有没有被别处使用?
回想一下这个 Key 有没有给过:代运营团队、第三方 ERP、自己写的脚本、其他采集软件。Ozon 后台看不到 Key 的调用来源,所以只能靠排查。最干净的办法还是换新 Key 并只给一处用。
限流会影响哪些操作?
所有走 API 的操作都会受影响:上架、改库存、改价格、同步订单。表现是这些功能同时失灵,而不是只有某一个坏掉——如果只有一个功能报错,那多半不是限流。