服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 官方指南更新于2026年10月1日，逐站判断创建结果的规则注明从10月16日起适用。
- 外层200代表请求已处理；site_items[] 内没有 error 的站点才创建成功，全部站点失败也可能返回200。
- 先确认卖家、目的站点、商品domain和尺码表资格；这不是所有卖家必须迁移的公告。
- 保留成功站点的商品ID，按失败原因决定后续动作；不要把整批重发当成通用修复方法。
- 创建后还要读取目的站点商品，核对尺码表ID、行ID与SIZE是否对应。
10月16日要改的，是你对“成功”的判断
如果你的 ERP 或刊登工具只凭 HTTP 200 就把整次创建标为成功，这次应优先检查。Mercado Libre 官方 CBT User Products 尺码表指南明确：2026年10月16日起，200只确认请求已经处理，不保证每个目的站点都创建了商品。
这份指南的更新日期是2026年10月1日，生效说明与文档更新日是两回事。影响范围是相关跨境刊登接口及逐站结果处理；它没有宣布所有 Mercado Libre 卖家都必须在10月16日前迁移，也不能套用到全部API。
CBT指跨境贸易，User Product简称UP，代表一组可售的商品属性组合，例如一种颜色加一种尺码。一个跨境请求可以涉及多个目的站点，业务结果必须按站点看，不能让一个绿色状态把失败项遮住。
先确认，你的卖家和商品能不能用这套流程
接入前先读取 GET /users/$USER_ID，确认公开 tags 数组包含 user_product_seller。目的站点还须已对该卖家及商品domain开放；官方示例里的站点代码是演示目标，不能直接当成所有账号可刊登的地区名单。
再通过官方的类目与domain发现接口确定商品所属范围，并在 GET /catalog/charts/CBT/configurations/active_domains 中确认它支持尺码表。domain可以理解为商品规格所属的类型；选了不匹配的类型，换一个尺码文字也不能解决。
按所选domain的 technical_specs?section=grids 读取允许的属性和值，再创建或取得兼容尺码表。每个UP在根 attributes 中关联 SIZE_GRID_ID、SIZE_GRID_ROW_ID、SIZE及要求的尺码属性，不使用 variations 数组拼出多个组合。
收到200以后，再看每个站点有没有 error
官方指南用 POST /global/user-products/families 创建UP家族：请求数组中每个元素是一组独立的可售组合，响应也逐元素返回。创建单个UP则使用 POST /global/items，发送对象而非外层数组；不要把两种返回结构混着解析。
对每个返回结果继续检查 site_items 数组。某个站点没有 site_items[].error，表示该站点商品创建成功；有 error，表示没有创建。部分站点成功、部分失败仍可返回200，全部站点都失败也可能返回200。
举一个假设场景：同一件M码商品要发布到两个已获授权的目的站点，A返回商品ID，B返回尺码表解析错误。正确记录是“A成功、B失败”，而不是把整次请求标为完成；这不是本文执行过的真实刊登结果。
还有一种情况要分开：外层返回全局4xx错误，并且没有 site_items，说明失败发生在站点级处理之前。它不是部分成功；应先修正全局请求，不能从空结果推断某个目的站点已经创建。
失败原因不同，下一步就不能相同
先保留失败站点的 error.status、error.error 及 cause 内的 code、message等实际字段。尺码表未找到、输入不足、表与商品domain不匹配，指向不同问题；只看外层200，或只截取一句错误描述，都会丢掉判断依据。
例如 domain_chart_mismatch 表示尺码表与刊登商品类型不匹配，chart_not_found 表示引用的表不存在或对卖家不可用。先核对表ID、商品类型及资格，再修正输入；不要看到所有错误都自动重试。
官方也列出 timeout、unavailable 等暂时性解析失败，提示稍后再试。它们与缺少 SIZE_GRID_ID、无效 SIZE 等既有校验错误并存；要结合错误代码和出现位置处理，不能把所有失败都归为网络或账号问题。
重试前，先留住已经成功的商品
收到部分成功结果后，先保存成功目的站点的商品ID，再检查被拒站点及原因。这些ID是后续核对已创建商品的线索；如果只保存一个“整批失败”状态，下次处理时就很容易忽略已完成的部分。
官方要求决定是否重试前，保留成功结果并考虑已经创建的目的站点。实际接入应让后续处理明确区分成功项和失败项，而不是无条件再次发送原始整批请求；修正后能采用哪条操作路径，仍以对应接口当前文档为准。
这份指南没有提供一个可直接调用的“仅重试失败站点”专用接口，也没有承诺整批重发不会重复创建。开发者应按本身的请求记录、已保存ID和实际错误设计后续动作，不从示例自行补出不存在的接口或幂等保证。
商品有了ID，还要确认尺码表没有挂错
对每个成功的 site_items[].item_id，使用自己的授权读取 GET /marketplace/items/$ITEM_ID。检查结果中的 SIZE_GRID_ID 是否为预期尺码表，SIZE_GRID_ROW_ID 是否对应目的站点解析出的行，以及 SIZE 是否与该UP和所选行一致。
目的站点解析后的行ID可能不同于来源行，也可能与其他目的站点不同。因此不能把“行ID都一样”当成跨站成功条件；应逐站核对实际尺码含义，让卖家看到的尺码与创建组合一致。
10月16日前最值得确认的，是工具能否拆分完整成功、部分成功、全部站点失败及全局请求错误，并保留逐站结果。发布完成应以目的站点商品和尺码关联核对为依据，而不是仅以请求返回200或工具显示绿色为依据。
资料来源
常见问题
一个UP家族里的组合，会一起成功或一起失败吗？
不会必然同步。家族请求中的每个元素代表一个独立UP，返回元素分别对应请求元素；还须继续判断每个UP内各目的站点的结果。不能仅看第一个组合就认定整个家族完成。
同样的尺码文字，能直接复用另一类商品的尺码表吗？
不能只凭尺码文字相同决定。应核对商品domain、该domain的尺码表技术规格和兼容表，保存对应表ID与来源行ID。官方列出了表与domain不匹配的站点级错误。
error.cause.references 为空，是不是没有真正的错误？
不是。官方示例中部分超时或暂时不可用错误的 references 可以为空数组，部分错误也可能省略诊断字段。仍应根据站点是否存在 error，以及返回的状态、代码和原因判断。