Coupang Open API：两个系统能否共用一个 Seller ID？

不可以——对于同一个 seller ID 或 vendor code，不能同时注册两个彼此独立的 Coupang Open API 集成。根据 Coupang 的官方密钥管理指南，该账户范围只允许一个 Open API 密钥。也就是说，不能同时注册多个服务商，也不能同时注册一个外部服务商和一套自研集成。

可行的架构是采用一个面向 Coupang 的连接器，将商品、订单、库存和结算数据路由至 ERP、仓储平台、财务系统及其他内部工具。

规则适用于每个 seller ID 或 vendor code

这一限制以账户为单位，而非以品牌为单位。如果企业拥有多个 seller ID 或 vendor code，应分别为每个账户制定集成方案；为一个账户选择的连接器不会自动覆盖另一个账户。

这一点在进入韩国市场时尤为重要。ERP、仓储平台和财务系统可能服务多个国家，但 Coupang 授权仍绑定在一个卖家账户范围内。应统计该范围内直接向 Coupang 注册的连接数量，而不是统计公司拥有的系统数量。

在选择工具前，先建立一份简明的账户映射表：

• 当前范围内准确的 seller ID 或 vendor code；
• 拟面向 Coupang 的连接器；
• 负责密钥的人员或服务；
• 需要接收数据的内部系统；以及
• 负责每项回写决策的系统。

需要核验的首要来源是 Coupang 官方 Open API 开发者文档，以及 WING 中的密钥管理流程。实施前请核对官方当前表述。不要只依赖笼统的兼容性声明，而应检查服务商文档中对商品、订单、库存、状态和结算的实际覆盖范围。

一个 Coupang 连接可以向多个系统提供数据

“直接连接 Coupang”与“接收 Coupang 数据”并非一回事。前者指使用 Open API 密钥向 Coupang 完成身份验证的系统；后者指从所选连接器接收数据的下游系统。这种传输可以通过导出、接口或内部数据管道完成。

一种实用架构可以是：

Coupang 卖家账户 → 一个面向 Coupang 的连接器 → ERP / 仓储平台 / 财务系统

在上述架构中，只有连接器直接调用 Coupang；下游流程能否运行，取决于连接器文档列出的接口及具体实现。只要这些接口支持所需流程，连接器便可统一标识符、分发记录，并接收内部系统批准的更新。ERP 和仓储平台不需要仅仅因为都需要订单或库存信息，就各自申请 Coupang 密钥。

应按业务流程逐项评估连接能力。

商品与目录运营

卖家工具或自定义服务可能需要创建、更新或维护商品及目录信息。上线前，应明确哪些记录必须在 Coupang 与内部系统之间流转：商品标识符、变体、卖家 SKU、商品刊登内容，以及适用时包括价格在内的商业字段。

不要含糊处理数据归属。如果 ERP 和卖家工具都能写入同一商品记录，应先确定优先级，否则相互竞争的更新可能互相覆盖。还应为每个字段指定权威系统，并明确连接器只是转发变更，还是也会对数据进行转换。

Coupang 的运营流程还可能将不同类型的更新分开。例如，为什么 Coupang 需要针对价格和库存分别调用 API 提醒我们，应核对服务商的实际覆盖范围，而不是想当然地认为“商品刊登管理”包含你所需的每一项商品操作。

订单与状态处理

连接器应将订单数据发送到负责处理订单的系统；如果履约模式要求回传，就将状态变更发送回 Coupang。应将异常路由至运营队列。

不要只问连接器能否“同步订单”，还要确认它实际提供哪些能力。确认用于将订单和订单行项目与内部记录匹配的标识符、状态变更如何呈现，以及更新延迟或被拒绝时系统如何处理。还应检查这些数据是否适合客户服务或 CRM 使用；Coupang 的 Open API 实际提供哪些客户数据说明了为什么不能自动把运营订单数据视为完整的客户档案。

库存相关操作

库存取决于履约模式。连接器可以读取可售库存、监控库存变动、协调补货，或传递经批准的库存更新，但可执行的操作取决于 Coupang 如何履行订单。

Rocket Growth 是一个尤其重要的例子。可售数量由 Coupang 在其履约中心实际接收的数量决定，因此，如果方案假定可以把所有内部库存数量直接推送到 Coupang，就存在风险。评估拟议库存流程是否符合履约模式时，请参阅为什么不能将库存数量推送到 Coupang Rocket Growth。

面向财务的结算数据

结算数据从一开始就应纳入集成需求。财务部门可能需要将 Coupang 的结算记录与订单、退货、内部收入记录及银行流水进行核对，而不仅仅是接收每日销售总额。

要在概念上区分订单状态、收入确认和结算时间。Coupang 何时将你的销售确认为收入介绍了基于配送的销售确认与之后冲回之间的差异。这一区分会影响记录标签和对账规则。上线前，应在连接器和财务系统中预先定义相关标签与规则。如果企业采用不同的结算周期，Coupang 结算时间表：按月、按周还是快速结算也与交接设计有关。

购买：让卖家工具成为注册连接器

购买路径是选择一个卖家工具或集成服务商，作为该 seller ID 或 vendor code 唯一注册的 Coupang 连接。ERP、仓储平台和财务系统可以继续保留在技术栈中，但应通过所选连接器接收数据，而不是分别向 Coupang 注册。

在授权服务商前，按以下顺序执行：

1. 定义所需流程。 列出上线所需的商品、目录、订单、状态、库存和结算操作。将每项标记为读取、写入或仅限内部交接。
2. 确认账户范围。 要求服务商确认它将连接哪个 seller ID 或 vendor code，以及其注册模式是否符合 Coupang 的官方单密钥要求。
3. 核实实际覆盖范围。 要求服务商逐项说明流程，包括其支持的标识符以及无法执行的操作。仅有商品刊登功能，并不能证明订单状态、库存或结算对账也在覆盖范围内。
4. 验证下游接口。 确认服务商如何向 ERP、仓储平台和财务系统开放数据。审查字段映射和更新方向，并确认服务商如何报告及修复失败或部分同步。
5. 明确权责。 确定哪个系统负责目录值、履约状态、库存决策和财务对账。服务商不应仅仅因为持有 Coupang 连接，就意外成为事实上的权威数据源。
6. 记录退出路径。 明确谁可以申请或接收替换密钥、如何导出映射，以及如何在不丢失运营历史的情况下断开现有服务商。

购买路径只有在服务商覆盖完整运营流程，或为缺失部分提供可靠接口时才可行。一个能处理目录变更、却无法向财务系统开放结算记录的卖家工具，可能在演示中满足要求，却无法满足上线条件。

自建：让一个内部服务充当连接器

自建意味着选择一个内部服务，作为该 seller ID 或 vendor code 唯一调用 Coupang 的组件。ERP、仓储平台和自定义脚本与该服务通信，而不是直接与 Coupang 通信。

该服务需要明确负责的不只是密钥本身，还包括以下事项：

• **密钥管理：**安全存储密钥、控制访问，并定义替换或撤销流程。
• **标识符映射：**将 Coupang 商品、货品、订单和状态标识符关联到内部 SKU、仓储记录和财务记录。
• **数据路由：**将正确的记录发送至 ERP、仓储平台、财务系统或运营队列，而不要求这些系统直接调用 Coupang。
• **监控：**检测身份验证失败、更新遗漏、变更被拒、重复记录和状态不一致。
• **对账：**将连接器记录与相关 Coupang 数据及内部账簿进行比对，防止未触发告警的同步失败演变为无法解释的库存或结算差异。
• **变更管理：**跟踪集成变更；当平台或运营模式发生变化时，重新审阅 Coupang 当前的开发者文档。

将连接器的职责与记录系统的职责分开。财务系统可能是对账的权威来源，仓储平台可能控制实物库存，而 ERP 可能负责主商品记录。自定义连接器负责转换和路由这些决策；它不必掌管每一项业务记录。

当你的数据模型或工作流程无法适配通用卖家工具，且团队有能力维护集成时，自建是更合适的选择。同时，这也带来长期运营责任：团队负责维护映射、监控、恢复流程以及未来的替换工作。无论选择哪条路径，单连接原则都不变。

为什么看似诱人的混合注册方案不受支持

常见提议是使用卖家工具处理日常运营，再使用自定义连接器补足缺失功能。这种拆分仍会为同一 seller ID 或 vendor code 建立多个直接注册。ERP 负责结算、卖家工具负责商品和订单时，情况同样如此。

一种实用设计是将自定义逻辑置于所选连接器之后，前提是该连接器开放所需接口。如果卖家工具充当连接器，就使用其支持的导出功能或接口，为中间件、ERP、仓储平台和财务系统提供数据。如果自定义服务充当连接器，就应让它明确取代卖家工具直接连接 Coupang 的角色，而不是让两个注册并行运行。

这是一项设计决策，不是可以拖到上线后再处理的权宜方案。先选卖家工具，之后才发现自定义代码无法置于其后，可能迫使你在最不合适的时点更换凭据、迁移数据并完成运营切换。

将密钥替换视为生产切换

重新签发 Coupang Open API 密钥并非无害的密码刷新。Coupang 的官方密钥管理指南明确，重新签发密钥会立即禁用旧密钥。因此，现有连接器可能在新密钥签发后立即无法通过身份验证。应将这项变更按生产切换进行规划。

一套受控的替换方案应包括以下步骤：

1. 盘点当前连接。 记录 seller ID 或 vendor code、当前服务商、密钥负责人、数据流、调度计划、映射，以及依赖该连接器的任何内部系统。
2. 定义新的权责模型。 确定哪个连接器将调用 Coupang，以及哪个系统负责商品、订单、库存和结算决策。更换凭据前先消除歧义。
3. 准备新的映射与接口。 先构建或配置下游交接。保留非机密配置，并记录新连接器将如何识别现有商品、订单、库存记录和结算周期。
4. 核对最后已知状态。 记录最近一次成功同步的时间点，并比较未完成订单、状态变更、库存记录及未结算数据。这为识别交接期间遗漏的记录提供基线。
5. 协调凭据变更。 如果涉及集成服务商，应提前约定谁接收新凭据、如何安全录入以及服务商何时激活。品牌方不应假定重新签发密钥会自动更新服务商。
6. 重新签发、激活并监控。 通过官方流程签发新密钥，激活选定连接器，并监控身份验证错误、重复或缺失记录、被拒绝的状态变更、库存差异和结算不匹配。新连接处理线上活动后，再次进行对账。

Coupang 的官方密钥管理指南在规划停用时同样重要。已过期的密钥可以重新签发，密钥也可以在过期前通过 WING 删除。这两种生命周期操作都不能为同一卖家账户下分别注册的两个集成创造一种受支持的并行运行方式；它们只是管理已选连接的控制手段。

常见问题

我的 ERP 和 Coupang 卖家工具可以同时使用同一个 seller ID 吗？

它们都可以接收相关数据，但不应针对同一个 seller ID 或 vendor code 分别注册为直接连接 Coupang 的 Open API 集成。请选择一个面向 Coupang 的连接器，并在内部路由数据。

单密钥规则是否意味着只有一个内部系统可以使用 Coupang 数据？

不是。该规则限制的是直接连接 Coupang 的集成数量。连接器可以通过受支持的导出功能、接口或中间件，将数据分发至多个内部系统。

购买卖家工具后，我还能添加自定义代码吗？

可以，只要自定义逻辑位于所选 Coupang 连接器之后，并使用该连接器提供的接口。针对同一卖家账户为自定义代码单独注册，则属于不受支持的混合方案。

当前密钥过期后会怎样？

Coupang 官方指导说明，已过期的密钥可以重新签发。如果服务商正在使用该密钥，应与服务商协调重新签发和激活，而不要把它当作仅限内部的变更。

替换服务商时会发生什么？

应将其视为生产切换。重新签发密钥会立即禁用旧密钥，因此在切换连接所有权前，需要完成凭据交接、测试映射、建立对账基线并启用线上监控。

在做出选择前，请核实：

1. 每个 seller ID 或 vendor code 的密钥由谁负责，谁有权安全地替换？
2. 连接的具体账户范围是什么？是否已有其他工具在该范围下完成注册？
3. 哪个系统是商品与目录数据、订单状态、库存决策和结算对账的权威来源？
4. 哪些流程是只读的，哪些需要回写？连接器将如何向 ERP、仓储平台和财务系统开放每项流程？
5. 团队将如何发现遗漏更新、被拒请求、重复记录、身份验证失败和对账差异？
6. 如果更换连接器，退出计划是什么——包括映射导出、凭据协调、历史数据保留和切换责任？

如果这些答案没有形成书面记录，连接器的选择就还没有完成。密钥不只是一个凭据；它决定哪个连接器负责通往 Coupang 的运营链路。