接一个数据 API 的技术动作其实很短：创建密钥、按文档发请求、检查状态码。快速开始和鉴权已经把这部分讲完了。
真正贵的不是这一步，是它前面那五个决策。它们的共同点是：当时随手定，跑起来以后改起来很痛。
决策一：调用量怎么估
这个数字决定你买哪个调用包，也决定后面四个决策的松紧。
估算时最常见的偏差是把"一份报告"当成一次调用。实际上一份竞品周报通常是：20 个 ASIN × 3 类字段 × 每周 1 次 = 60 次调用，如果还要拉 12 个月的历史序列做对比，第一次跑完可能是几百次。
按这个公式估：实体数 × 字段类别数 × 频率，然后单独把"首次回填"算成一笔一次性支出。首跑和稳态运行的量级经常差一个数量级，只按稳态估会在第一天就超预算。
决策二：哪些字段落库，哪些实时取
判断依据只有一个：这个字段多久变一次。
| 变化速度 | 典型字段 | 建议 |
|---|---|---|
| 基本不变 | ASIN、品牌、类目、上架时间 | 落库，只在缺失时补 |
| 按天变 | BSR、评分数、销量估算 | 落库 + 定时刷新 |
| 随时变 | 价格、优惠券、库存状态 | 实时取，不要缓存过夜 |
两个方向都会浪费钱：什么都不存，等于为一批从不变化的数据反复付费；什么都存，等于拿着过期的价格做决策。
把表设计成"慢字段一张表、快字段一张带时间戳的流水表"，比事后拆容易得多。没有时间戳的数值在三个月后就无法判断还能不能用。
决策三：重试策略要分类，不能统一处理
这是最容易写错的一处。失败不是一种，重试逻辑也不该只有一套。
| 状态码 | 典型错误码 | 重试有意义吗 | 处理方式 |
|---|---|---|---|
400 | VALIDATION_ERROR | 否 | 请求内容不变时重试只会重复失败 |
401 | INVALID_API_KEY、API_KEY_EXPIRED | 否 | 换密钥，不要退避重试 |
402 | INSUFFICIENT_CREDITS | 否 | 余额不足，重试多少次都不会成功 |
403 | ENDPOINT_NOT_INCLUDED | 否 | 套餐不包含该接口 |
413 | — | 否 | 请求体超过 64 KB，要拆批 |
429 | RATE_LIMIT_EXCEEDED、CONCURRENCY_LIMIT_EXCEEDED | 是 | 按 Retry-After 退避 |
503、504 | SERVICE_BUSY、SERVICE_TIMEOUT | 是 | 指数退避 + 随机抖动 |
402 和 429 长得像但不是一类问题。 429 是"现在太快了，等一会儿"，退避就能过去；402 是"钱花完了"，它需要的是告警和充值流程，不是重试循环。把两者写进同一个 catch 分支，结果是余额耗尽那天你的任务在安静地空转。
同理，429 里的两个错误码也不同：RATE_LIMIT_EXCEEDED 是每分钟请求数超了，CONCURRENCY_LIMIT_EXCEEDED 是同时在途的请求太多。前者靠降频解决，后者靠降低并发解决——降频不会降并发。
响应里这三个头是用来做这件事的：
| 请求头 | 说明 |
|---|---|
X-RateLimit-Limit | 当前分钟窗口允许的请求数 |
X-RateLimit-Remaining | 当前窗口剩余请求数 |
X-RateLimit-Reset | 窗口重置时间，Unix 秒级时间戳 |
别等到 429 才反应。在 X-RateLimit-Remaining 掉到阈值以下时就主动减速，比被限流后退避的吞吐高。
至于失败的请求会不会扣额度，不要靠猜。已登录用户可以在用量页面看到请求元数据，脱敏后的请求体和响应保留 7 天——上线前故意触发一次失败，然后去调用明细里核对一次，比任何推测都可靠。
错误码与限流文档完整状态码表、错误码清单、限流请求头和调用明细的保留规则决策四：并发是账户级预算，不是任务级参数
这条最反直觉，也最容易在扩容时踩：
RPM、并发数和 Credits 按账户汇总，不能通过创建多个 API Key 获得额外配额。
很多团队的第一反应是"给每个任务发一把自己的密钥"，以为这样各跑各的。实际上三个定时任务各开 10 条连接，账户面对的就是 30 条并发，谁先跑谁把别人挤成 CONCURRENCY_LIMIT_EXCEEDED。
所以并发要设计成一个全局共享的限流器，而不是每个任务各写各的。具体做法：
- 所有调用走同一个客户端封装，限流器在封装里，不在业务代码里
- 给不同任务分优先级——实时接口的查询优先于夜间回填
- 回填任务显式限速，它不着急，但它最容易把配额吃光
还有一个上限值得提前知道：请求体超过 64 KB 会返回 413。批量接口传 ASIN 列表时，这个上限决定了单批的最大条数，要在分批逻辑里写死，而不是等线上报错。
决策五：团队里密钥怎么管
既然配额本来就是账户共享的，多建密钥不是为了配额。它真正的价值是另外两件事：归属和独立吊销。
按用途分配，而不是按人：
prod-api、cron-backfill、dev-local这样分，出问题时能从调用明细直接定位到是哪条链路- 某条链路出事，停掉那一把，其他照跑
- 有人离职，要盘的是他接触过哪几把，而不是整个账户
三条底线：密钥只存服务端环境变量，不进仓库，不进前端代码。任何需要在浏览器里调用的场景，都应该由你自己的后端中转。
这五个决策的共同点
它们都不是技术难题，而是改起来成本不对称的选择。调用量估错，第一个月就会发现；缓存策略选错，要等到数据开始对不上；重试写成一套，要等到余额告罄那天；并发按任务设计，要等到第三个任务上线；密钥按人发，要等到第一次离职。
写第一行请求代码之前花半小时把这五条定下来，比上线后回来改省得多。
接下来选接口时，亚马逊数据 API 完全指南按业务场景拆了 46 个接口；如果还在判断该不该走第三方接口这条路，先看亚马逊数据 API 怎么选。
常见问题
多创建几个 API Key 能提高限额吗？ 不能。RPM、并发数和 Credits 都按账户汇总。多密钥的价值在归属和独立吊销，不在配额。
429 之后应该等多久？
优先按响应里的 Retry-After。没有这个头时用指数退避加随机抖动，避免多个任务在同一时刻一起重试。
怎么确认失败请求有没有扣额度？ 在用量页面查调用明细。脱敏后的请求元数据保留 7 天，上线前主动触发一次失败核对一遍即可。
批量接口一次最多传多少条？ 没有统一答案，受请求体 64 KB 上限约束。按你实际的参数长度算一次，然后在分批逻辑里留出余量。