用 Make 打通跨境电商订单全流程:从下单到发货的完整自动化方案(含实战代码)

最近在项目中遇到一个问题,跨境电商店铺的订单需要在 Shopify、Amazon、eBay 三个平台同步,随后自动推送到自建的 ERP 系统,再生成国际物流标签并通知买家。手工操作每单要耗费 5~10 分钟,错误率也不低。于是我把整个链路搬到 Make(原 Integromat),做了一套全链路自动化。下面把思路、实现细节以及踩坑经验完整拆解,供同行参考。

1. 原理分析:Make 的模块化工作流如何匹配跨境电商需求

Make 本质上是一个 可视化的 API 编排平台,核心概念包括:

Scenario(场景):一条完整的业务流程,由一系列模块串联而成。
模块:对应一次 API 调用、数据转换或脚本执行。常见的有 HTTP、JSON 解析、过滤器、迭代器、JavaScript。
路径(Path):同一场景内的分支逻辑,支持条件分支、错误分支。

跨境电商的订单生命周期大体分为 获取订单 → 标准化 → 库存/价格校验 → ERP 写入 → 物流标签生成 → 买家通知。每一步都可以映射为 Make 的模块组合。关键在于:

统一订单格式:不同平台的订单结构差异大,需要先把它们转换成内部统一的 JSON(如 order_id、sku、qty、buyer_address、currency)。
实时性 vs 批量:订单产生后需要即时处理,而库存同步可以采用批量模式。Make 支持定时触发(cron)和 webhook 双模式。
容错和重试:跨境物流 API 往往有频率限制,必须在场景里加入 错误分支 与 延迟重试。

2. 实践应用:从零搭建完整的订单自动化流程

2.1 场景概览

graph TD
    A[Webhook 接收新订单] --> B[统一订单结构]
    B --> C{平台类型}
    C -->|Shopify| D[Shopify API 调用]
    C -->|Amazon| E[Amazon MWS 调用]
    C -->|eBay| F[eBay Trading API]
    D --> G[库存校验]
    E --> G
    F --> G
    G --> H[写入 ERP(REST)]
    H --> I[生成物流标签(Shippo)]
    I --> J[发送邮件/短信给买家]
    J --> K[日志 & 监控]

这里用了 Mermaid 语法,直接复制到 Make 的 Markdown 模块即可预览。

2.2 关键模块配置细节

2.2.1 Webhook 捕获订单

在 Shopify、Amazon、eBay 的后台分别配置 Webhook,指向 Make 提供的 URL(https://hook.make.com/xxxx)。
Webhook 负载为原始 JSON,随后使用 JSON 解析 模块提取关键字段。

2.2.2 统一订单结构(JavaScript 模块)

// 输入变量:shopifyPayload、amazonPayload、ebayPayload
function normalize(payload, source) {
  if (source === 'shopify') {
    return {
      order_id: payload.id,
      platform: 'shopify',
      sku: payload.line_items[0].sku,
      qty: payload.line_items[0].quantity,
      currency: payload.currency,
      buyer_address: {
        name: payload.shipping_address.name,
        street: payload.shipping_address.address1,
        city: payload.shipping_address.city,
        country: payload.shipping_address.country_code,
        postal_code: payload.shipping_address.zip
      }
    };
  }
  // 省略 Amazon、eBay 的映射逻辑,思路相同
}
let order = {};
if (shopifyPayload) order = normalize(shopifyPayload, 'shopify');
else if (amazonPayload) order = normalize(amazonPayload, 'amazon');
else if (ebayPayload) order = normalize(ebayPayload, 'ebay');
return order;

关键点:统一字段命名,后续所有模块只需要处理这一个 JSON 结构。

2.2.3 库存校验(迭代器 + HTTP)

使用 迭代器 把 order.sku 列表展开,每个 SKU 调用自建库存系统的 REST 接口 GET /stock/{sku}。
通过 过滤器 判断 available_qty >= order.qty,不满足时走 错误分支,发送 Slack 报警。

2.2.4 ERP 写入(HTTP POST)

{
  \"order_id\": \"{{order.order_id}}\",
  \"platform\": \"{{order.platform}}\",
  \"items\": [
    {
      \"sku\": \"{{order.sku}}\",
      \"quantity\": {{order.qty}}
    }
  ],
  \"shipping\": {
    \"name\": \"{{order.buyer_address.name}}\",
    \"street\": \"{{order.buyer_address.street}}\",
    \"city\": \"{{order.buyer_address.city}}\",
    \"country\": \"{{order.buyer_address.country}}\",
    \"postal_code\": \"{{order.buyer_address.postal_code}}\"
  },
  \"currency\": \"{{order.currency}}\"
}

这里使用 Make 的模板 语法 {{}} 注入变量。返回的 ERP 单号会保存到 order.erp_no,供后续物流使用。

2.2.5 生成物流标签(Shippo API)

调用 Shippo 的 POST /shipments/ 接口,传入收件地址与 ERP 单号。
接口会返回 label_url 与 tracking_number,随后写回 ERP(PUT /orders/{erp_no})并进入下一步。

2.2.6 买家通知(邮件 + 短信)

使用 SendGrid 发送邮件模板,内容包含 tracking_number、label_url。
同时调用 Twilio 发送短信,保证买家在微信/WhatsApp 之外也能及时获知。

2.2.7 日志与监控

所有关键节点写入 Google Sheets 或 Datadog,方便业务方审计。
通过 Error Handler 捕获未处理异常,自动向 Telegram 发送告警。

3. 踩坑经验:真实项目中遇到的五大阻碍

API 限流导致订单丢失
- Amazon MWS 每秒只能 1 次请求。解决办法是把 迭代器的并发数调到 1,并在错误分支里加入 Wait 模块(延迟 2 秒)后重试。
时区不一致导致发货日期错位
- Shopify 返回的时间是 UTC,ERP 要求本地时区。使用 JavaScript 模块统一转为 Asia/Shanghai,并在日期字段加上 format('YYYY-MM-DD')。
字符编码导致地址中文乱码
- 部分老旧物流 API 只能接受 GBK。Make 本身只支持 UTF‐8,需要在 HTTP 模块里手动把 payload 用 iconv-lite 转码(在脚本模块中实现)。
税号校验规则多变
- 跨境电商必须在订单中附加买家的 VAT/HSN。最稳妥的做法是把 校验规则抽象成 JSON 配置文件,放在 Google Drive,场景里读取后用 JavaScript 动态匹配。
Webhook 重复推送
- 某平台在网络波动时会重发相同订单。通过 过滤器 对比 order_id 与 Google Sheets 中的已处理列表,实现幂等处理。

4. 最佳实践汇总

环节	推荐做法
触发	优先使用 Webhook,配合 Cron 做容错补偿
数据标准化	统一字段命名,所有后续模块只依赖一个 JSON Schema
错误处理	每个关键调用都设置错误分支,配合 Wait + Retry
幂等性	通过订单唯一标识在持久化表(Google Sheets / DB)做去重
监控	关键节点发送日志到 Datadog,异常即时告警
性能	对高频 API 采用批量请求(如一次请求获取多 SKU 库存)
文档	用 Mermaid 绘制流程图,放在项目 Wiki,便于新人快速上手

关键在于 可维护性:当业务加入新渠道(如 TikTok Shop)时,只需要新增一个 Webhook + 转换脚本,其余流程无需改动。

5. 小结:从思路到落地的完整路径

思考原理:先弄清业务流程与各系统的 API 能力。
拆解模块:把每一步映射为 Make 的模块,确保每个模块职责单一。
实现并测试:在 sandbox 环境先跑几笔,验证数据一致性。
上线监控:加入日志、告警、幂等校验,降低运营风险。

如果你也在为跨境订单的多平台同步、仓库对接或物流标签生成头疼,不妨尝试把这套思路搬到自己的 Make 场景里。实际落地后,你会发现手工操作的痛点几乎消失,订单处理速度提升 3~5 倍,错误率降到可接受范围内。

说实话,这套方案不是“一键即用”,仍需要根据各自的系统文档做细节调研。但一旦搭建完毕,后期的扩展与维护成本会大幅下降。祝大家玩得开心,业务飞涨!