对于依赖ERP（企业资源计划系统）、第三方软件或自建系统批量管理商品和订单的卖家来说，这些变化意味着后续需要重点检查API调用频率、订单同步接口以及商品数据结构，避免因接口变更影响日常运营。

从9月14日起，Trend­yol按照卖家商品刊登上限对Product API（商品接口）进行分级限流。官方目前将卖家的商品上限划分为100,000件、350,000件、500,000件和Unlimited（不限量）4个等级，并分别设置不同的API调用频率。

商品读取服务（Product Integration Read）分别为每分钟1000、1250、1500和2000次；商品写入服务（Product Integration Write）分别为每分钟200、300、400和500次；库存与价格写入服务（Inventory & Price Write）则分别为每分钟350、500、1000和1500次。

需要注意的是，这里的限流并不是针对每一个接口单独计算，而是按照服务组统一计算。比如，一名商品上限为100,000件的卖家，商品写入服务每分钟最多只能调用200次。

如果这一分钟内已经完成50次商品创建、100次商品更新和50次商品删除，刚好达到200次，那么这一分钟内该服务组下其他写入操作也不能继续调用。也就是说，卖家不能简单地把不同接口的额度分别计算，而需要把同一服务组中的请求量放在一起管理。

商品读取服务同样采取合并计算方式，包括商品筛选（Product Filter）、批量处理结果查询（Check Batch Result Service）、退货及收货地址信息、品牌列表、类目列表、类目属性列表、类目属性值列表以及商品质检审核状态查询等多个服务都会共同占用Product Integration Read额度。

商品创建、商品更新、Buybox检查、品牌创建、商品归档、商品解锁和商品删除等操作，则统一计入Product Integration Write额度；库存和价格更新则共同计入Inventory & Price Write额度。

此外，价格更新还增加了一道更细的限制：同一个条形码（barcode）每分钟最多只能发送30次价格更新请求。如果卖家针对同一个条形码在一分钟内发送超过30次请求，该条形码对应的请求将在Batch Result Service（批量处理结果服务）中返回错误。

对于SKU（库存量单位）较多、经常通过系统批量调价的卖家而言，需要特别检查系统是否存在短时间内重复推送价格的情况。

与9月14日的限流调整相比，订单接口的变化更加直接。Trend­yol已宣布，原有订单API将在10月15日正式废弃。在此之前，卖家需要将订单系统迁移至Order V2（订单V2接口）。

从7月30日Trend­yol公布的过渡安排来看，旧订单接口在10月15日前仍可使用，但每天会有3次、每次10分钟的“brownout”（计划性短暂停用）时段，期间请求会返回426错误码，以推动卖家完成迁移。

新的Order V2接口还设置了单次最多返回10,000条记录的限制，即maxQueryWindowResult最大值为10,000。

对于需要长期、大批量抓取订单数据的卖家，Trend­yol此前已经提供了getShipmentPackagesStream接口，通过基于游标的流式方式（cursor-based streaming）处理大规模数据扫描、周期性同步以及全部订单导出；该接口可以获取最近3个月的订单数据。

与此同时，Trend­yol还在8月17日调整了商品原产地信息的管理方式。过去，Country of Origin（原产国）信息主要放在Attribute（属性）字段中，现在平台新增了独立的origin字段，将原产地信息与stockCode、barcode等标准字段分开管理。

目前这一变化处于过渡期。如果某个商品类目要求必须填写原产地，那么卖家在过渡期间仍需要按照原有方式在attributes中填写，同时也可以选择通过新的origin字段提交。从10月23日起，origin字段将正式变为必填项，而attributes中的原产地信息则变为可选。

对于历史数据，Trend­yol表示，在截止日期到来后，原先保存在attributes中的原产地信息会由平台自动迁移到新的origin字段，卖家不需要手动搬运历史数据。

从这几项调整可以看出，Trend­yol近期正在持续整理商品和订单接口的数据结构，同时进一步控制API资源的使用方式。

作者✎  Summer/垚锋声明：此文章版权归垚锋所有，未经允许不得转载，如需授权请联系: amz123happy