Tracking API 与 Shipping API：您的电商技术栈需要哪一个（还是两者都需要）？
当您的电子商务技术栈需要创建货件并生成运输标签时，请使用运输 API。当您的技术栈需要在发货后跟踪货件，并将承运商更新转化为有用的运营信息或面向客户的信息时，请使用跟踪 API。如果您的软件必须管理货件创建和购买后的可见性，则需要这两种能力，但不一定需要两个供应商或两个独立的集成。
这一决策应由负责履约架构的人员做出：通常是与工程团队合作的电子商务运营负责人。首先确定您的商店、仓库或履约合作伙伴已经处理了哪些事项。添加另一个 API 应该是为了弥补特定缺口，而不是重复已经正常运行的工作流程。
跟踪 API 和运输 API 有什么区别？
两者的区别主要在于每个 API 执行的任务，而不是产品类别之间存在严格的界限。运输平台可能包含跟踪端点，而跟踪服务也可能提供通知和面向客户的配送更新工具。请评估文档中列出的端点和事件行为，而不要仅依据产品名称做判断。
| 决策维度 | 跟踪 API | 运输 API |
|---|---|---|
| 主要任务 | 检索或接收货件状态和跟踪事件。 | 创建货件并获取标签及相关运输文件。 |
| 典型输入 | 跟踪号码、承运商标识符，以及任何其他所需的货件详情。 | 寄件人和收件人详情、包裹信息、服务选择以及适用的海关数据。 |
| 典型输出 | 货件状态、事件历史记录和其他可用的配送信息。 | 货件标识符、标签和受支持的文件。 |
| 主要工作流程 | 配送可见性、异常处理和购买后更新。 | 仓库发货和出库货件准备。 |
| 不要做出的假设 | 跟踪访问权限包含标签创建或承运商预约。 | 标签创建包含您所需的跟踪深度和通知控制功能。 |
承运商文档体现了这种区分。FedEx 在其 Ship API 文档中说明货件创建，并在其 跟踪 API 文档中说明跟踪能力。这些是不同技术职责的示例，并不表示建议选择某个特定承运商。
创建货件不等同于观察其运输过程
成功的货件创建响应只能告诉您的软件运输请求已被处理，并不能证明承运商已经实际接收包裹。同样，跟踪号码可能在运输历史中出现物流移动之前就已经存在。
因此，您的订单管理系统应区分标签创建、仓库交接、承运商接收和配送。将这些全部视为单一的“已发货”事件，可能会导致过早向客户发送消息，并掩盖实际上尚未离开仓库的包裹。
选择能够解决当前瓶颈的能力
当发货是缺失环节时选择运输 API
当您的应用需要将订单数据转化为货件时，运输 API 是合适的起点。例如，仓库团队需要手动将地址复制到承运商门户，或者自定义订单管理系统无法生成标签。
在选择集成之前，请明确实际的发货流程。您是否只需要创建货件，还是还需要获取运费、取消、取件请求、海关文件或日终处理？这些功能可能属于独立 API，取决于承运商，或需要额外的账户权限。不要假设标有“运输 API”的产品包含所有运输操作。
不适合作为唯一解决方案：一种标签创建集成，却让您的客户服务团队仍需逐一检查承运商网站。它可以解决发货问题，但配送可见性基本不会改变。
当货件创建已经正常运行时选择跟踪 API
当标签已经由您的仓库管理系统、履约合作伙伴、平台或现有运输集成创建，但配送信息较为分散时，跟踪 API 更为直接适用。
在这种情况下，替换标签工作流程可能增加迁移工作，却无法解决核心问题。相反，应将上游生成的跟踪号码连接到一个可供订单管理系统、支持工具和客户沟通使用的可见性层。
对于这一类别，17TRACK Tracking API 是一个相关的集成选项。其官方 API 文档介绍了跟踪号码注册和跟踪数据工作流程，包括推送通知。请根据您所需的承运商、货件类型和应用架构评估这些工作流程。这是对跟踪层的考量，并不意味着该服务可以替代标签生成集成。
不适合作为唯一解决方案：当您的软件仍无法创建其负责发出的货件时使用跟踪 API。跟踪可见性无法解决运输执行缺失的问题。
当应用同时负责发货和配送可见性时使用两者
当您的技术栈必须生成标签并持续可靠地查看货件进度时，两种能力都适用。它们可以来自同一平台、不同服务，或由承运商集成与跟踪层组合提供。
当某个集成的运输和跟踪功能能够满足您记录在案的要求，且无需做出不必要的妥协时，优先选择一个集成。当现有运输工作流程值得保留，或跟踪要求与该工作流程提供的功能存在实质差异时，可以考虑独立集成。独立跟踪供应商并不一定更好；它必须证明额外的集成、计费和运营管理是合理的。
两种 API 如何融入电子商务技术栈
实用的设计应将订单、货件和跟踪事件作为独立记录保存。一个订单可能产生多个包裹，每个包裹也可能拥有自己的跟踪历史。面向客户的订单状态应根据这些货件记录生成，而不是覆盖这些记录。
- 订单准备好履约。商店或订单管理系统将所需的履约数据发送给负责的仓库。
- 运输工作流程创建货件。应用保存返回的货件标识符、跟踪号码、承运商、服务和标签引用。
- 仓库完成交接。仓库确认和承运商接收应保持为可区分的事件。
- 跟踪工作流程开始。应用根据所选集成的要求注册或提交跟踪号码。
- 跟踪更新到达应用。Webhook、轮询或受支持的组合机制将更新写入货件记录。
- 业务规则决定下一步。系统在满足相关条件时更新面向客户的状态、创建运营任务或发送消息。
例如，使用第三方履约仓库的商家可能只需在自有软件中执行第四至第六步。仓库已经负责创建货件。自行运营仓库的商家可能需要完整流程。
为每项下游操作指定一个负责人
如果两个集成都提供跟踪更新，请指定哪个系统负责控制客户通知以及商店中显示的货件状态。否则，客户可能会收到重复消息，或看到相互冲突的配送状态。
您可以保留辅助数据以供调查，但不要允许每个来源都触发电子邮件。保留原始承运商事件以及内部状态映射，以便支持人员了解系统为何以特定方式对货件进行分类。
比较运营适配性，而不是功能标签
核实您实际使用的承运商和服务
承运商支持不是一个简单的是或否问题。某项服务可能支持某承运商的跟踪，却不支持该承运商的标签创建。标签创建还可能取决于始发国、承运商账户设置或服务资格。
根据实际运输线路建立测试清单。包括国内包裹、国际货件以及运输合作伙伴之间的任何交接。确认每项所需操作：创建货件、跟踪货件，或两者都需要。对业务所依赖服务进行成功测试，比笼统的覆盖范围声明更有用。
检查事件含义和数据完整性
对于跟踪，请测试首次扫描前、配送异常期间、配送尝试失败后以及完成配送时的处理方式。检查时间戳是否包含时区信息，以及原始承运商描述是否仍然可用。
不要将标准化状态理解为所有承运商都提供相同数据的承诺。预计送达日期、位置详情和签收证明可能取决于底层承运商和货件。当这些字段缺失时，请确定界面的行为。
检查两端的故障恢复
对于运输，在创建货件期间发生超时需要特别注意：即使应用没有收到响应，请求也可能已经成功。盲目重试之前，请核实供应商支持的重复防止和对账机制。
对于跟踪，请测试重复通知、延迟事件、Webhook 传送失败和临时端点中断。在相关文档中确认身份验证、重试行为和恢复选项。设计事件处理流程，确保重放更新不会再次发送相同的客户通知。
比较总运营成本，不要预设定价模式
将 API 费用与邮资和承运商账户费用分开。运输服务和跟踪服务可能使用不同的计费单位，综合平台也可能以不同方式打包这些能力。请针对计划运行的确切工作流程获取报价或查看适用方案。
询问计费使用量如何定义、不成功的请求是否计费、重复提交跟踪如何处理，以及使用量超过限额时会发生什么。将工程维护、支持工作以及保持两个集成一致的成本纳入考量。在没有明确的货件组合和当前商业条款的情况下，宣称某一类别更便宜会产生误导。
审查安全性和数据保留
运输集成可能会处理收件人地址和海关信息。跟踪集成也可能会处理货件标识符及相关客户数据。确认所需字段，将凭据限制为必要的访问权限，并确保机密信息不出现在浏览器端代码中。
根据业务要求审查数据保留、删除和访问控制。便捷的集成不应要求发送工作流程不需要的客户信息。
承诺之前的实际验证计划
使用具有代表性的货件开展概念验证，而不仅仅是使用快速入门指南中的成功示例。与运营、工程和客户支持团队共同确定验收标准。
- 发货：生成所需的标签格式，并确认仓库设备可以使用这些标签。
- 订单映射：测试拆分货件、多个包裹和替换货件，同时不丢失原始历史记录。
- 跟踪：检查与业务相关的承运商和路线的真实事件序列。
- 异常：验证可执行的配送问题是否到达正确团队，而不会自动将每次异常扫描都视为失败。
- 恢复：中断请求或 Webhook 端点，并演示应用如何对缺失信息进行对账。
- 通信：确认每条客户通知仅由指定系统发送。
- 商业适配性：根据预期使用量和供应商确认的计费定义估算费用。
决策规则：优先购买缺失的能力。如果发货已经正常运行，请评估跟踪集成，而不要重建履约流程。如果缺少标签创建功能，则先解决运输执行问题。如果您的应用负责完整的货件生命周期，请验证两种能力，并选择对团队而言更易运营的综合架构或分离架构。
常见问题
运输 API 是否总是包含跟踪功能？
不一定。有些服务同时包含两种能力，而其他服务则通过独立端点、产品或方案提供这些能力。即使包含跟踪功能，也应在将其作为购买后跟踪解决方案之前，核实其事件详细程度、更新交付方式、承运商支持和使用条款。
我可以跟踪由履约合作伙伴创建标签的包裹吗？
有可能。您的应用需要跟踪集成所要求的标识符，通常包括跟踪号码，并在需要时包括承运商标识符或其他验证信息。请确认是否支持合作伙伴使用的承运商，并确保跟踪号码可靠地流入您的系统。
跟踪 API 会让承运商更快进行扫描吗？
它无法创建实际的承运商扫描记录，但可以帮助您的应用检索、整理和分发跟踪来源提供的信息。请使用实际货件评估更新行为，而不要假设 API 能保证立即看到每一次移动。
要使用两种能力，我是否需要两个 API 供应商？
不需要。您需要的是两种功能，而不一定是两个供应商。当一个供应商能够满足您的运输和跟踪要求时，可以使用一个供应商。当分开使用能够保留正常运行的工作流程，或满足综合选项无法满足的特定要求时，再将它们分开。
跟踪 API 可以替代订单管理系统吗？
不能。跟踪数据是订单管理的输入，而不是库存分配、履约决策、付款处理或订单记录的替代品。您的应用仍需将每个货件关联到正确订单，并决定货件事件如何影响业务工作流程。
来源
- FedEx Ship API 文档 — 货件创建、标签和运输工作流程要求的参考资料。
- FedEx 跟踪 API 文档 — 跟踪请求和货件状态信息的参考资料。
- 17TRACK Tracking API — 跟踪集成类别的官方产品参考。
- 17TRACK API 文档 — 跟踪注册、跟踪数据和推送通知集成的参考资料。
