GOFO 物流接口

GOFO 物流接口接入指南

面向区域履约优化的 GOFO API 方案,支持与主承运商组合运行,提升多承运商策略的执行弹性。

物流接口概览

不支持的地址:不支持 APO/FPO/DPO 等军事及外交地址,以及 PO BOX 信箱地址派送。即使目的地 ZIP 在覆盖范围内,也不支持这类地址。

GOFO API 适合按区域与包裹结构做路线优化。团队可先小批量试单验证时效与计费口径,再逐步扩大业务范围。

查询 GOFO 方案时,请先选择 Parcel、Economy 或 Ground,再输入发货 ZIP、目的地 ZIP、重量尺寸和商品类型。比较总成本时,除 DAS、DSS、EDAS 与 EDAS* 等目的地费用,还应核对 Parcel 的超尺寸费、超重费与超最大限制费;交仓地点与截单安排由服务方案提供。 查看 GOFO 服务 · 查看 Parcel 包裹限制与收费 · 了解 GOFO 覆盖与交件。

开发者收益

  • 统一接口结构,便于在多承运商环境复用集成逻辑。
  • 支持按区域策略分流,便于实现 多承运商组合 路由规则。
  • 追踪与账单字段可关联,便于运营与财务协同核对。
评估项 接入前应明确什么
区域边界 团队要明确哪些州和城市群适合先走 GOFO
主承运关系 清楚 GOFO 是主路径、补位路径还是峰值备份路径
核对口径 区域试单后的 轨迹、账单和退款字段必须可比对

什么时候 GOFO API 比全国型基线更值得优先评估

如果你的订单高度集中在特定区域、对区域履约效率更敏感,或者已经有一条主承运基线但需要补充局部优化路径,那么 GOFO API 的价值会非常直接。它更像对某些订单段的精细化补位,而不是替代所有全国履约能力。最有效的方式通常不是全量切换,而是先从少量区域和稳定订单类型开始,通过小批量试单验证计费、轨迹和异常处理是否真的更合适。

集成示例

POST /v1/order/quotation
{
  "order_id": "ORDER-20001",
  "ship_from_zip": "91761",
  "ship_to_zip": "90001",
  "weight_lb": 0.8,
  "carrier": "GOFO"
}

POST /v1/order
{
  "order_id": "ORDER-20001",
  "carrier": "GOFO",
  "service": "standard"
}

GET /v1/order/{shipment_code}

常见问题

GOFO API 更适合什么类型的订单?

通常更适合区域集中、需要局部优化或补充基线路径的订单段。

GOFO API 是否应该一开始就全量上线?

一般不建议。先从少量区域和稳定订单类型试单,更容易验证适配度。

它更适合作为主承运还是补充路径?

多数情况下更像补充或优化型路径,具体取决于区域结构和现有基线。

GOFO API 接入后如何避免核对复杂化?

关键是保持 order_id、shipment_code 和账单字段在跨承运商环境中仍然可对齐。