Trendyol订单接口10月15日换代，换个地址还不够

9月8日下午，Trendyol的一部分新订单没有出现在订单服务返回结果里。平台随后在维护公告中要求合作方重新查询14时至15时34分这段记录。顾客已经下单，店铺自己的系统却可能没有拿到完整资料；重新恢复连接，和把这一段订单补齐，是两件不同的事。

这份通知出现在Trendyol官方更新日志中。同一日志还记录了另一项即将发生的变化：旧订单查询服务将在10月15日退出使用，卖家须迁移到Order V2。到10月4日，距离这项期限还有一段准备时间，适合重新查看店铺每天怎样取得、识别和处理订单。

AI生成场景示意：土耳其电商团队核对订单资料与待发包裹

接入工具负责请求，业务人员负责发货，财务人员负责单据，三方通常各看自己的一块结果。一次接口切换如果只被理解成技术人员改了一个地址，就容易遗漏真正的经营目标：顾客已经完成的交易，要在店铺里形成完整、可处理且不会重复执行的记录。

十月十五日，变的是哪一段订单流程

Trendyol的当前订单包查询文档明确标注，10月15日起须使用V2订单接口。它提供的是订单包数据查询入口，卖家依赖这个入口把平台交易接入自己的仓库、发货或经营系统。期限针对所列旧查询接口，不能扩写成平台全部业务接口同一天停止。

更新日志还说明，在截止日之前，旧服务每天会有三次、每次十分钟返回426错误的安排。这种阶段性提示，目的是推动迁移。对于收到这一错误的团队，继续把它当作偶发网络问题重试，最多只能等待这次短暂停用过去，并没有完成版本切换。

限流又是另一回事。文档提到，高频请求可能遇到429错误，它对应请求量与服务限制。错误代码虽然都让一次查询没有完成，原因和处理方向却不同。团队若把所有失败都合并成“平台暂时没订单”，经营人员就无法区分确实没有新记录，还是数据尚未取得。

运营负责人可以先问工具供应方三个具体问题：当前实际调用哪个订单版本，截止日前怎样完成切换，以及切换前后是否有一份订单包核对结果。答案需要对应店铺正在运行的接入，而不是软件产品介绍里一句泛泛的“支持Trendyol”。

多店团队还要分别确认。某个账户已经接入新版本，不意味着其他店铺用的独立配置也同步完成；主系统已经更新，历史导出、客服查单或另一个库存工具也可能继续使用旧入口。只记录一个“升级完成”状态，容易掩盖这些单独维护的调用。

这类维护可以有清楚的范围：哪些系统读取平台订单，读取之后交给哪些业务流程，发生失败时由谁处理。负责人不必掌握每项程序细节，但需要知道哪份数据到达仓库，哪份记录进入单据，哪一处遗漏会让实际顾客等待。接口管理一旦能对应具体经营工作，迁移就有可以检查的结果。

一万条窗口，数的是包裹记录

Order V2文档最容易被误读的数字，是一万条。官方把它定义为通过分页可访问的记录窗口，并明确依据shipmentPackageId，也就是订单包标识计数。它不是店铺每天最多接一万笔订单，也不是一次请求会给出一万条记录。

订单号与订单包标识各有用途。一笔订单分成不同包裹时，对应的包裹记录分别参与这一窗口计数。经营团队用订单号分析交易，仓库按包裹安排出货，这两类数量原本就不一定相同。查询设计若把它们混在一起，最后看到的总量也会失去解释。

单次请求最多返回200个包裹，是另一项限制。卖家不能因为返回结果中显示的总页数较大，就认为所有页面都能通过同一个宽泛条件继续取得。官方文档特别说明，符合查询条件的总记录数可能超过可访问窗口，超过的部分需要改变查询方式。

这个机制会在大范围历史取数时显现。团队准备把一段时期的交易全部导入报表，查询本身能够成功，前面几页也都有数据；如果只把“每次都返回正常”作为完成依据，仍可能没有拿到整个范围。是否完整，需要对照所选条件下的总记录及实际已取回的包裹，而不是只看最后一次请求。

文档给出缩小日期、按需要细分条件及改用流式查询等方向。业务人员要做的是先明确目的：为了发出待处理包裹，还是为了核对一段时间的变化，抑或准备导出经营资料。目的不同，筛选条件也不同，不必让所有工作都反复扫描最大的一段数据。

缩小日期同样需要有边界。每段分别确认结果是否超出窗口，各段之间保持衔接，完成后检查同一包裹是否重复进入记录。若只是凭感觉把大范围拆成几个小范围，忙完之后仍可能不知道中间有没有空档。日期分段是取数办法，核对完整性才是它要达成的结果。

订单状态还会变化。顾客下单后，包裹进入准备、开票、发出或其他状态，经营系统需要接到后续更新。只按第一次创建的记录判断整个订单过程，不能回答今天仓库需要做什么。正在用于同步的工具，应当明确它如何获得已存在包裹的新状态，并把变化交给正确流程。

大批量同步，需要跟着下一段继续取

Trendyol的流式订单包查询说明为较大数据扫描、周期同步与订单导出提供了另一种入口。它采用游标方式，取完一段后，利用返回的下一段位置继续取得，直到平台表示没有更多结果。这个位置由平台生成，不应自行解析或修改。

“游标”听起来像技术术语，经营上可以理解为一次连续取数的进度。上一段完成，下一段沿着同一次筛选继续。它不能被简单当作原来的页码换一个名字，也不能仍然依赖旧的总页数字段判断是否结束。

当前文档列明，这个入口可以访问最近三个月的数据，每次时间范围最多十四天；没有提供相应修改时间起止条件时，系统会使用最近两周范围。普通订单查询与流式查询的资料范围不同，团队不能因为换了取数方式，就默认任意历史时期都可以回来。

文档还要求，在沿用同一游标时保持最初筛选条件。取到一半改状态或换时间，继续使用旧位置，就不再是原来那次扫描。需要新的筛选，应开始新的取数过程。对于运营负责人，最值得保留的是这次任务究竟查什么、从哪里开始、有没有正常结束。

一份同步记录可以非常克制：

• 范围：对应店铺、时间区间与所选状态，说明本次取数要服务哪项业务。
• 进度：已经取得哪些包裹，平台是否还有下一段，任务在哪里中断。
• 完成：是否取得平台给出的正常结束结果，是否存在尚未处理的错误。
• 核对：与平台经营记录比较时，用订单号还是包裹标识，二者不要混计。
• 接手：补取得到的数据进入哪一流程，怎样避免同一包裹再次发货。

这个记录不是为了给每次请求增加人工签字。工具可以自动保存进度，业务人员需要在异常时看得懂它。若一段同步没有完成，报表就应知道所用数据还不完整，仓库也应知道哪些记录已经进入出货安排。信息及时到达相关人员，才不会把缺数变成“今天生意比较淡”的错误判断。

断点后的补取，尤其要照顾已有动作。同一包裹第一次出现时，仓库可能已经拣货；补取又拿到它，系统应更新或核对相应记录，而不是重复生成新的出货任务。反过来，一条此前确实遗漏的记录，则要能进入正常待处理流程。防止重复与发现遗漏，需要同时成立。

这也解释了为何迁移后的验证应该覆盖整个业务结果。能查询第一段，只证明连接和一部分解析有效；能够继续取到结束、识别已有包裹、处理新记录，并把状态正确传到下一环节，才更接近店铺每天需要的能力。

支付方式也进了订单资料，发票要接得住

九月的更新并不只有查询问题。平台9月9日在同一官方日志中公布，订单包查询与Webhook模型加入paymentMethod字段，并要求接入方读取它，以便准确记录发票中的付款方式。旧系统即使继续拿到了商品、金额与地址，也可能把这项新增资料忽略。

官方Webhook模型与查询示例中都能看到这项字段。列出的值涵盖银行卡、信用卡、购物信贷、Trendpay钱包、Trendpay先买后付及一个横线值。卖家不应凭自己的默认习惯，把所有订单都写成同一种付款方式。

这里需要区分付款方式与卖家结算。消费者选择怎样支付，是订单中的一项交易资料；平台什么时候、以什么账单向卖家结算，是另一套经营问题。新字段的出现，并不能推导某笔交易款项已经进入卖家余额，也不能替代真实结算记录。

工具能够接收字段之后，仍要核对它被送到了哪里。订单列表可能已经显示，开票工具却继续使用旧模板；另一种情况是内部翻译把不同原始值统一成同一个中文名称。业务团队应保留能与平台记录对应的资料，再按实际开票流程使用，避免在部门交接中改变含义。

通知回调与主动查询也要保持一致。Trendyol说明新增字段涉及两种资料入口，卖家如果两种都用，不能只更新其中一种。否则，同一包裹先后从不同入口进入系统，资料完整程度可能不同，财务同事也难以判断为什么某些订单有值、另一些没有。

文章能从平台资料确认的是这项字段与接入要求。具体单据如何开具，还须按照卖家真实交易、适用规则与实际系统安排。把官方提供的交易资料接全，是后续处理的基础；不能用一次接口升级来概括全部当地开票责任。

换代前，拿真实订单把交接走完

九月两次中断通知提供了一种直接的经营提醒。9月2日，平台曾要求补查当地GMT+3时区15时29分至16时01分的订单；9月8日又要求补查另一段记录。这是已发生事件的处理窗口，不是当前每天都在中断，也不代表所有店铺都受到相同影响。

日期与时区必须留在同一份任务里。中国团队收到通知后，若只复制钟点却没有保留事件日期与原时区，补取就可能查到另一段资料。平台文档对不同时间字段的含义也有说明，具体筛选应由接入人员按所用字段核对，运营端则确认目标事件和业务范围。

距离十月十五日尚有准备时间，团队可以选用少量真实包裹复核：已经出货的、仍待处理的、有状态变化的，以及用到不同付款方式的。检查它们能否在新入口被识别，商品与数量是否完整，已有动作有没有被保留，新资料是否进入相应单据。这样的核对能直接对应仓库和财务工作。

完成切换后，再确认旧入口是否仍在被其他任务调用，未完成取数是否得到处理。仅把错误消息藏起来、让报表继续生成，并没有解决订单遗漏；让负责人知道数据完整到哪里，反而更有助于及时安排补查和出货。

Trendyol的这轮接口更新，正在把版本、查询范围、包裹识别和单据资料一起推到卖家面前。十月十五日前最值得交付的成果，是一份可以从平台交易一直核对到实际出货的订单记录，而不只是一个已经替换的连接地址。

声明：本文系作者独立观点，不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性，实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流，欢迎随时与我们联系。