Amazon Ads API 接入实战：自用卖家从申请到安全验证

实际用途	申请身份	说明
只管理自己公司的广告账户	Direct Advertiser	适合内部工具和自用自动化
管理客户账户，或向第三方提供 SaaS	Partner	通常还涉及 Partner Network 和更严格的合规要求

当时 RongAds 只服务于我自己的广告账户，因此走 Direct Advertiser。申请材料也应如实写成“内部工具、仅管理自有账户”，不要为了显得功能强大而声称会管理第三方客户。

申请前先准备这些东西

开始申请前，建议一次准备好：

由公司长期控制的 Amazon 登录邮箱；
能正常访问 Amazon Ads Console 的广告账户；
公司法定名称、网站和联系邮箱；
一段与真实功能一致的英文用途说明；
一个自己控制的 HTTPS OAuth 回调地址；
第一阶段明确只做读取还是同时做写入。

我更建议第一版只声明和实现读取广告活动、profile 与报表。即便最终要自动调价，也应该先证明数据来自正确的站点和账户。

可参考下面的用途描述，并按真实情况调整：

We are a direct advertiser developing an internal application exclusively for managing and optimizing our own Amazon Ads accounts. The application will retrieve campaign and performance data and generate internal recommendations. It will not be offered to third parties, and advertising data will not be sold or shared.

创建 LwA 应用并提交访问申请

在 Amazon Developer Console 中创建一个独立的 Login with Amazon Security Profile。不要直接复用 SP-API 的凭据，也不要把 Client Secret 写入 Git、截图或聊天记录。

Security Profile 至少需要配置：

应用名称和说明；
隐私政策地址；
Web Settings 中精确匹配的 Allowed Return URL。

回调地址必须是自己控制的 HTTPS 地址，例如：

https://ads.example.com/oauth/amazon/callback

协议、域名、路径和末尾斜杠都应与程序发起授权时使用的 redirect_uri 完全一致。

随后以 Direct Advertiser 身份提交 Amazon Ads API 访问申请。审批通过后，还要打开审批入口，把权限绑定到刚才创建的 LwA Security Profile，并确认应用获得 advertising::campaign_management scope。

为什么“已获批”仍然不能读取广告数据

我自己的实际进度正好说明了这个区别。

截至 2026 年 7 月 14 日：

Direct Advertiser API access 已通过；
RongAds Internal Advertising Tool 已与 LwA 应用绑定；
控制台已经显示 advertising::campaign_management scope；
广告账户已经完成 EU OAuth 授权，授权凭据已在服务器以 0600 权限保存；
OAuth 回调服务和 RongAds UI/API 均已上线，但德国站 Profile 白名单与只读报表对账还没有完成。

所以当前准确的说法是“广告账户已经连接，可以开始只读验证”，还不能说德国站 Profile 已经核验，更不能说 RongAds 已经在自动调价。

真正的数据权限来自广告账户用户的 OAuth 同意。应用最终能看到和修改什么，也受这个授权用户自身权限限制。

OAuth 授权应该怎样设计

服务端先生成一次性随机 state，保存到当前登录会话，再把用户引导到欧洲区域的 LwA 授权页面：

https://eu.account.amazon.com/ap/oa
  ?client_id=你的_CLIENT_ID
  &scope=advertising::campaign_management
  &response_type=code
  &redirect_uri=URL编码后的回调地址
  &state=服务端生成的一次性随机值

Amazon 回调时会带回 code 和 state。程序必须先验证 state，再在服务端使用授权码、Client ID 和 Client Secret 交换令牌。

这里有几条硬规则：

Client Secret、授权码和 Token 不进入浏览器日志、前端页面或截图；
授权码是短期、一次性的，失败后重新发起授权，不重复使用旧 code；
Refresh Token 只保存在服务端密钥文件或密钥管理器；
Access Token 只作为短期凭证使用，过期后由 Refresh Token 换新；
回调端必须验证 state，避免授权结果被串换。

先取得并白名单德国站 Profile ID

拿到有效 Access Token 后，第一步不要写竞价，而是调用欧洲区域的 Profiles 接口：

curl 'https://advertising-api-eu.amazon.com/v2/profiles' 
  --header 'Authorization: Bearer ACCESS_TOKEN' 
  --header 'Amazon-Advertising-API-ClientId: CLIENT_ID'

从响应里找到 countryCode 为 DE 的 profile，并同时核对账户名称、币种和站点。之后访问大多数广告资源时，需要携带：

Authorization: Bearer <短期 Access Token>
Amazon-Advertising-API-ClientId: <Client ID>
Amazon-Advertising-API-Scope: <德国站 Profile ID>

Seller ID、Marketplace ID 和 Campaign ID 都不能代替 Profile ID。多站点或多账户环境中，Profile 用错是很危险的错误，因此不要只保存一个裸数字，应该同时保存国家、币种和可识别的账户名称，并建立白名单。

第一阶段只做这三个验收

我当时给 RongAds 设定的第一阶段验收不是“成功改一次竞价”，而是：

能读取 EU profiles，并唯一确认德国站目标账户；
能拉取一份只读广告报表，且数据能与控制台或 Bulk 文件对上；
能保存请求时间、Profile、报表请求 ID 和原始响应，错误时有明确日志。

只有这三件事稳定，才说明认证、站点、账户范围和数据口径基本正确。

自动调价前必须有的保护

OAuth scope 本身并不会替内部工具限制“最多改多少”。如果直接开放写操作，Profile 选错、币种误读、批量范围错误或程序缺陷都可能造成真实广告损失。

最低限度应具备：

默认 dry-run：先生成修改前后差异，不直接提交；
人工确认：按批次审核后再执行；
Profile 白名单：同时校验国家、币种和账户名称；
硬上限：限制单次调价幅度、预算上限、单批数量和每日修改次数；
审计日志：记录谁、何时、为什么把什么值从多少改到多少；
修改前快照：为回滚保留原值；
kill switch：异常时能立即停止所有自动写入；
Bulk 兜底：API 迁移期间保留已经验证过的人工导入导出路径。

对小型自用工具来说，“可解释、可预览、可回滚”通常比“全自动”更重要。

当时计划的实现顺序

当时的计划是风险递增：

已完成 OAuth 回调和服务端凭据存储；
读取 EU profiles，白名单锁定德国站；
拉取只读报表，与现有 Bulk 数据核对；
建立历史快照和异常日志；
写操作先只生成预览；
小批量人工确认写回；
最后才评估日频自动调价。

这条路比“拿到 API 就立刻自动化”慢一点，但它能让每一步都有证据，也能在任何阶段退回当前稳定的 Bulk 工作流。

后来怎么样了

这条路后来又走了一段：API 服务、调度器和自动驾驶进程都上过服务器，但始终只在 off 和 dry-run，没有一次真实写入。2026 年 10 月，我把 API 接入连同整套自动化删除，RongAds 回到只读 Bulk 文件的形态，作为免费网站开放。原因写在《Amazon 广告自动调价：我给 RongAds 加了 7 道安全闸，然后把自动化删了》的末尾，一句话版本：自动执行的前提是持续拉数和保管凭据，这和“不保存用户数据”互斥；而每天自动跑相比每周手动跑，效果上没有差别。“任何阶段都能退回 Bulk 工作流”这一条，最后真的用上了。

常见问题

Ads API 和 SP-API 可以共用凭据吗？

不应假设可以。广告 API 与卖家订单、库存、结算使用的 SP-API 是两条独立轨道，申请、授权、端点和数据模型都不同。

已经看到 campaign management scope，为什么仍然报未授权？

Scope 说明应用已经获得 API 能力；具体广告账户仍要由有权限的用户完成 OAuth 授权，并由程序取得有效 Token 和 Profile ID。

能不能直接用 Seller Central 主账号授权？

技术上取决于账号权限，但不建议长期用最高权限主账号作为自动化身份。更稳妥的做法是使用独立、最小权限的广告用户，并把写操作继续放在人审闸门后。

官方资料

本文记录的是 2026 年 7 月的接入路径。Amazon 可能调整控制台入口、权限模型和 API 版本，正式实施时应以最新官方文档和实际返回结果为准。