为什么无法向 Coupang Rocket Growth 推送库存数量

在 Coupang Rocket Growth 上，你无法推送库存数量。可售数量取决于 Coupang 在其配送中心实际收货并接收的数量——入库收货记录本身就是你的库存数字，而不是你在某个字段中填写、或通过 API 调用写入的数值。这与卖家自配送商品的运作方式恰恰相反，也会悄然打乱你从 Amazon 或 Shopify 沿用过来的任何库存同步逻辑。

这一区别之所以重要，是因为大多数西方团队往往会假设两件事之一：要么存在一个可供编辑的数量字段，要么任何平台 API 都能调整库存。但在 Rocket Growth（로켓그로스）上，两者都不成立。如果你的集成建立在这一假设之上，它就会悄无声息地失效——写入操作从未生效，商家也收不到任何报错，而第一个显现的症状便是一次谁也解释不清的断货。

核心规则：收货记录即你的库存数量

对于 Rocket Growth 商品而言，可售数量反映的是在 Coupang 配送中心实际入库并被接收的货物。Coupang 官方开发者文档对此有明确说明：对于 Rocket Growth 商品，入库数量即体现为商品数量，标准的商品数量变更功能并不适用。

通俗地讲——对于 Rocket Growth 商品，并不存在"将数量设为 500"这样的操作。Coupang 清点到货码头上收到的货物，这一计数便成为你的可售数量。你只能通过发货和入库来影响它，而无法通过编辑某个数值来改变它。

这也解释了商品所有权和库存流转为何以这种方式运作：货架上的货物在售出前仍归你所有，但驱动商品可售状态的计数，是 Coupang 的收货记录，而非你自行维护的数字。若想厘清你所拥有的库存与 Coupang 所清点的库存之间的界限，我们在另一篇文章中已单独探讨——参见发往 Coupang Rocket Growth 应寄送什么，以及货物归谁所有。

为何这与卖家自配送商品不同

在卖家自配送（平台）商品上，库存由你持有，你也有责任告知 Coupang 有多少件可供销售。在这种模式下，你可以自行调整商品数量——这一数字由你拥有并维护，随着自有仓库库存的消耗而更新。

Rocket Growth 则颠覆了这一逻辑。由于货物由 Coupang 持有并发货，计数也随之归 Coupang 所有。这对工具集成的影响十分具体：Rocket Growth 商品无法通过用于展示和修改卖家自配送商品的那些 Open API 路径来查询和调整。允许平台卖家更改商品数量的那个端点，根本就不是 Rocket Growth SKU 所使用的机制。

这会以一种特定的方式让集成出错。许多库存同步方案将"更新 Coupang 上的数量"视为适用于所有商品的单一操作。事实并非如此。即便对平台商品而言，价格与库存在 Coupang API 上也早已分属不同的处理逻辑——我们在为什么 Coupang 的价格与库存需要分别调用 API 一文中已梳理过这一区分——而 Rocket Growth 则完全取消了库存写入。如果你的同步逻辑只写一套并套用到所有商品上，那么 Rocket Growth SKU 会接受请求路径，却不会按你的预期执行。

• 卖家自配送： 由你设定并调整可售数量；这一数字由你维护。
• Rocket Growth： 可售数量由 Coupang 的入库收货记录决定；不存在设置数量的调用。
• 共同陷阱： 一套为所有商品编写的同步例程，会悄然错误地处理 Rocket Growth 商品。

你仍可以通过程序控制哪些内容

失去数量写入并不意味着 Rocket Growth 是一个黑箱。根据 Coupang 开发者文档，你对 Rocket Growth 商品保留的操作杠杆是商业性和运营性的——而非数量。实际上，你仍然可以：

• 更改销售价格。
• 更改折扣基准价。
• 暂停和恢复某商品的销售。
• 读取订单和读取客户咨询。

留意这份清单的构成。你所保留的一切，要么是定价决策，要么是可售状态开关，要么是读取操作。唯一缺失的，是写入库存数量的能力——因为库存数量本就不由你写入。在正式上线之前，这一点值得深刻领会：你为 Rocket Growth 制定的自动化路线图，应围绕价格、促销、可售状态以及订单/咨询读取来构建，并应默认补货是通过物流环节完成的，而非某个 API 字段。

防止断货成为一道物流课题

以下这一视角的转变，才是真正改变你人员配置与规划方式的关键。由于你无法为某个数量字段补充数值，Rocket Growth 上的断货防范便成为一道物流节奏的课题，而非库存字段更新的课题。你无法通过更快地编辑数字来防止断货——你只能通过足够提前地入库适量货物来防止断货。

这意味着你的规划输入随之改变。你不再是盯着库存滑块去调整它，而是依据销售周转速度和运输前置时间进行预测，再倒推出一个补货触发点，将整条链路都纳入考量：生产或拣货、发往韩国的货运、清关及入库配送中心，以及 Coupang 的收货确认。收货这一步，正是各团队最容易忽略的环节——在途或滞留在到货码头的货物尚不可售，因为它们还未被清点。

这里真正的前置时间发生在仓库上游——它是你的发货节奏与收货所需时长之和，这也正是我们将 Rocket Growth 入库最低量与真实前置时间 视为主导补货的关键指标、而非以码头吞吐量本身为准的原因。日常运营节奏同样有帮助：一次简短的例行复盘，关注销售周转和入库状态，便能在仍有时间发货之际捕捉到即将到来的断货——这也是对韩国账户进行午间巡检在标准作业流程中占有一席之地的部分原因。

常见问题

我能通过 Coupang Open API 设置 Rocket Growth 商品的数量吗？ 不能。Coupang 开发者文档指出，对于 Rocket Growth 商品，入库数量即体现为商品数量，商品数量变更功能不适用。数量由配送中心的实际收货记录决定。

为什么我的库存同步在 Rocket Growth SKU 上会悄然失效？ 因为 Rocket Growth 商品无法通过与卖家自配送商品相同的 Open API 端点进行调整。为平台商品构建的同步例程所指向的路径，无法改变 Rocket Growth 的数量，商家也不会收到任何有意义的报错。

对 Rocket Growth 商品，我仍能自动化哪些内容？ 根据 Coupang 文档，你可以更改价格、更改折扣基准价、暂停和恢复销售，以及读取订单和客户咨询。这些控制项均为商业性和运营性的——而非数量。

如果无法推送库存，我该如何防止断货？ 依据销售周转速度和运输前置时间进行预测，再设定包含入库到收货窗口在内的补货触发点。货物只有在 Coupang 收货并接收后才可售，因此你的节奏——入库的频率和数量——才是保障可售状态的关键。

我可以在哪里核实这些信息？ Coupang 官方开发者文档是了解 Rocket Growth 商品在 Open API 上如何运作的权威来源，包括哪些写入操作适用、哪些不适用于配送商品。