你写的同步脚本跑着跑着开始成片返回 HTTP 429，这就是撞上了 SP-API rate limit（速率限制）。先给结论：SP-API 用令牌桶限流，每个操作（operation）都有自己的「速率」和「突发」两个数，大多数操作按「卖家账号 × 你的应用」这一对单独计算；超限返回 429，可以重试，但必须退避。以下机制与数字均为 2026年9月29日在亚马逊开发者文档（developer-docs.amazon.com）实查。
这篇只讲使用计划（Usage Plans）和限流本身。怎么注册开发者、怎么授权、SP-API 和 MWS 的整体差别，看亚马逊销售伙伴 API VS MWS；调某个操作需要哪个角色，看亚马逊销售伙伴 API 中的角色。
SP-API rate limit 怎么算：令牌桶
官方《Usage Plans and Rate Limits》页（2026年9月29日实查）的说法是：SP-API 用令牌桶算法限流，每个令牌换一次请求；系统按固定的「每秒速率」往桶里加令牌，加到桶的上限为止，这个上限就是突发（burst）。每发一次请求扣一个令牌，桶空了还发，请求就被限流、返回错误。
官方页用一个「速率 1、突发 2」的操作举例，换成人话是这样：
- 桶一开始是满的，有 2 个令牌。连发两次，两次都成功，桶空了。
- 紧接着发第三次，被限流。
- 过 1 秒，桶里补回 1 个令牌，可以再调一次。
- 再过 1 秒又补 1 个，桶回到 2 个就不再往上加。
所以两个数各管一件事：速率决定你长期能跑多快，突发决定你攒着不用之后能一口气连发几次。表里写 0.0167，意思是每秒补 0.0167 个令牌，折合约 1 分钟 1 个。
使用计划由什么决定
同一页列出了分配使用计划的三个因素（2026年9月29日实查）：
- 操作本身：每个操作有自己的默认速率和突发，写在该操作的 API 参考文档里。
- 卖家账号 × 应用这一对：多数操作的配额按这一对计算。同一个应用替另一个卖家调、用另一个区域账号的凭证调，或者另一个应用替同一个卖家调，都是各自一个新桶。例外是免授权操作（grantless operations），它们不需要卖家授权，配额按其余因素定。
- 区域与站点：配额隐含地绑在卖家所在的站点组上，不同站点的卖家账号有不同的卖家 ID，也就各算各的。
还有一点常被忽略：一个操作可以同时挂多个使用计划，先触达哪条就按哪条限流。官方《Optimize Rate Limits for Application Workloads》页以 Listings API 为例，说明它既有按卖家账号的限额，也有按应用的限额，应用级限额是跨所有卖家共享的总阀门。
标准计划和动态计划
官方页把使用计划分成两类（2026年9月29日实查）：
| 类型 | 怎么定 | 你该怎么对待 |
|---|---|---|
| 标准计划 | 大多数 API 用这种；对所有调用方是同一组静态值，按该操作的预期调用模式设定 | 直接按文档里的数字规划 |
| 动态计划 | 部分 API 和操作使用；按卖家当前和历史的业务指标自动调高或调低 | 读响应头，别把数字写死 |
动态计划有两点官方写得很明确：一是调整依据只看卖家的业务指标，不看历史请求量，你调得越勤并不会让配额变大；二是调整以「不频繁、不破坏」为目标，业务指标出现有意义的变化时才改。旧版资料里常说「订单 API 用动态计划」，这次实查的官方页没有点名哪些 API 属于动态计划，以你实际收到的响应头为准。
怎么看你自己的实际配额
调用成功后看响应头 x-amzn-RateLimit-Limit，它给出这个操作在当前「账号 × 应用」下的速率。但官方页（2026年9月29日实查）明确说不能依赖它一定出现：
- 系统偶尔取不到配额时，照样返回正常结果，只是不带这个头；
- 只有 HTTP 20x、400、404 响应带这个头，未授权或未认证的请求不带；
- 它只反映一条使用计划，不包含同一操作上的其他限额（比如应用级限额）。
我们的做法是：以文档数字做容量规划，以响应头做运行时校准，两者不一致时记日志，别让程序直接信任其中任何一个。
常用操作的现行配额
下表逐条摘自 developer-docs.amazon.com 各 API 的 Rate Limits 页，2026年9月29日实查，速率单位是「次/秒」。只列取到现行值的操作，没取到的一律不列。
| API（版本） | 操作 | 速率（账号×应用） | 应用级速率 | 突发 | 折算 |
|---|---|---|---|---|---|
| Orders v2026-01-01 | searchOrders | 0.0056 | — | 20 | 约 3 分钟 1 次 |
| Orders v2026-01-01 | getOrder | 0.5 | — | 30 | 2 秒 1 次 |
| Orders v0 | getOrders | 0.0167 | — | 20 | 约 1 分钟 1 次 |
| Orders v0 | getOrderItems | 0.5 | — | 30 | 2 秒 1 次 |
| Orders v0 | confirmShipment | 2 | — | 10 | 每秒 2 次 |
| Feeds v2021-06-30 | createFeed | 0.0083 | 不适用 | 15 | 约 2 分钟 1 次 |
| Feeds v2021-06-30 | getFeed | 2 | 不适用 | 15 | 每秒 2 次 |
| Feeds v2021-06-30 | getFeeds / getFeedDocument | 0.0222 | 不适用 | 10 | 约 45 秒 1 次 |
| Catalog Items（最新版） | getCatalogItem | 2 | 250 | 2 | 桶很浅 |
| Catalog Items（最新版） | searchCatalogItems | 2 | 500 | 2 | 关键词搜索另限应用级 50 次/秒 |
| Listings Items v2021-08-01 | getListingsItem / putListingsItem / deleteListingsItem / searchListingsItems | 5 | 100 | 5 | 每秒 5 次 |
| Listings Items v2021-08-01 | patchListingsItem | 5 | 500 | 5 | 改关系或商品数据属性另限应用级 100 次/秒，校验预览 20 次/秒 |
表外两条同页附注也要记住：createFeed 提交 JSON_LISTINGS_FEED 类型时，每个账号每 5 分钟最多 5 个 feed、每个 feed 最多 25,000 条记录；getCatalogItem 的附注建议按 ASIN 批量取数时改用 searchCatalogItems。报告（Reports）和定价（Product Pricing）两组接口这次没取到现行表格，不列数字，用之前请直接查官方对应的 Rate Limits 页。
按配额倒推调度
有了表，就能倒推一个任务该怎么排。拿订单同步举例：
getOrders速率约 1 分钟 1 次、突发 20。每页结果翻下一页也是一次请求、同样扣令牌，所以一次同步要翻 10 页，就会一口气用掉桶里一半的令牌。按 5 到 10 分钟一轮增量同步是稳的，按秒轮询一定撞墙。- 新版
searchOrders更紧，约 3 分钟才补 1 个令牌，适合定时增量查询，不适合拿来做「实时」看板。 - 要逐单取明细时，
getOrder、getOrderItems每秒 0.5 次，1,000 单就是大约 33 分钟，这个时间要算进任务窗口。
改价、改库存这类写操作，Listings 的账号级速率是每秒 5 次，但应用级另有上限；你的应用服务的卖家越多，越要在服务端做统一的限速队列，而不是每个卖家各开一个线程猛发。想看一整套取数落地的做法，可以对照亚马逊数据看板 DIY。
收到 429 怎么处理
官方 FAQ 的原话意思是：429 是可重试的状态码，可以再试，但反复被限流的请求需要退避策略；而且就算你调用得很规范，也不能完全避免偶发的 429，代码里要为它留位置。《Optimize Rate Limits for Application Workloads》页（2026年9月29日实查）给出的做法，整理成可以照做的清单：
- 先限速再发：在客户端放一个限速器，按每个操作的速率匀速发请求，避免「一阵猛发、一阵空闲」的尖峰流量。官方 SDK 自带限速器，超限时抛出限流错误，你需要自己捕获处理。
- 重试加指数退避：连续失败时等待时间逐次拉长，同时加随机抖动（jitter），避免所有任务在同一时刻一起重试又一起被限。
- 少发请求：能用通知就别轮询，比如价格变了靠通知触发改价，而不是每隔几秒查一次；能批量就别逐条，Feeds 和 Reports 一次调用能带更多数据；常用数据做缓存。
- 把 429 当指标看：记录状态码、响应头和错误信息，按操作分类统计，给 429 比例设告警阈值。
沙箱只能用来测你的 429 处理逻辑，测不了真实配额：官方页说明生产环境各操作速率不同，而沙箱里所有操作共用同一个速率。
配额不够用怎么办
先确认是调用方式的问题还是配额本身的问题。官方的立场是：配额按「高效调用模式理想情况下不该被限流」来设，持续被限流通常说明调用模式还能优化，默认速率确实不够时，参照上面那份优化指南调整。另外三条官方口径（2026年9月29日实查）：
- 亚马逊可以随时调高配额；如果要调低 API 参考文档里公布的数字，会提前通知，留出改代码和测试的时间。
- 授权你的卖家变多，不会让你每个卖家的配额变少，因为配额按「卖家 × 应用」一对计算，吞吐量随客户数自然增长。
- 动态计划下被持续限流，多半是调用模式没对齐这个卖家被分配的配额，而不是系统出错。
顺带一句：Product Advertising API 是另一套
搜「amazon product advertising api rate limits」的人常会找到这里，但 Product Advertising API（PA-API）是给联盟推广者取商品数据用的，和卖家用的 SP-API 不是一个体系，上面的配额都不适用。2026年9月29日实查 PA-API 5 官方文档的 API Rates 页，现在显示的是弃用通知：PA-API 5 已被 Creators API 取代，继续调用 PA-API 5 会收到 HTTP 403 AccessDeniedException，需要按官方迁移指南改接 Creators API。
延伸阅读
- 亚马逊销售伙伴 API VS MWS：注册、授权、调用流程全套
- 亚马逊销售伙伴 API 中的角色：每个操作需要哪个角色
- 亚马逊数据看板 DIY：用 SP-API 把数据拉进表格的实操
- 亚马逊即将推出全新 API：SP-API 推出前后的背景