網店與市集

物流狀態自動寫回訂單

一個追蹤編號同時存在於三個地方——物流商的系統、一張試算表，以及最終那張訂單——然後由人手在三者之間搬來搬去。「我件貨去到邊」的查詢就是這樣來的：不是因為件貨遲了，而是因為那張訂單的狀態兩日之前就停止更新。物流狀態是要主動查詢的，不會自己推送過來，所以這裡的形狀是輪詢；而真正重要的一步，是把結果寫回客戶看得到的地方。

觸發: 兩個
執行頻率: 每 30 分鐘
工具: 4 件
需要 durable execution: 不需要

流程

上面那條在出貨一刻把追蹤編號記低一次，下面那條定時向物流商查詢，只有狀態真的變過才寫回去。

▶ 平台

訂單出貨

Shopify Admin API

編排

記下追蹤編號

n8n · Make

資料

寫入出貨紀錄

Sheets · Airtable

▶ 編排

每 30 分鐘

n8n 排程

平台

向物流商查詢

DHL Shipment Tracking API

編排

狀態是否有變？

n8n IF

平台

寫回訂單

Shopify Admin API

編排

維持原紀錄

—

逐步拆解

01
訂單出貨
Shopify Admin API
建立出貨紀錄時 webhook 觸發。把它當成「追蹤編號開始存在」的一刻，而不是它的最終版本——那個編號有時一小時後會被更正。
02
記下追蹤編號
n8n · Make
把編號連同它屬於哪一間物流商、來自哪一張訂單一併存起。物流商同編號一樣重要：不知道要向誰查，同一串字元本身沒有意義。
03
寫入出貨紀錄
Sheets · Airtable
一次出貨一行，記住最後見到的狀態，以及見到的時間。第二欄的作用，是防止流程就同一個狀態再通知客戶一次。
04
每 30 分鐘
n8n 排程
要主動查，不能等——物流狀態本身就是查詢式的。查詢頻率按物流商的配額來定，而不是按你希望數據有多新來定；配額才是真正的限制，而且比大部分人以為的細。
05
向物流商查詢
DHL Shipment Tracking API
只查仍在運送中的出貨。已簽收的不會再變，繼續查它們只會消耗配額，而那些配額你會想留給仍在移動的包裹。
06
狀態是否有變？
n8n IF
同紀錄上最後一個狀態比較，不要同一張固定清單比較。物流商重複回報同一次掃描，不應該被讀成有進展，否則客戶會收到兩封一樣的郵件，然後對下一封信心減一分。
07
寫回訂單
Shopify Admin API
更新出貨紀錄上的物流資訊，並且刻意決定這一次變動值不值得發一封信。中途每一次掃描都不值得；出倉、派送中、派送失敗，就值得。

平台不容許的事

這個流程頭上有兩重上限：物流商肯回答你的頻率，以及寫回去之後網店會怎樣處理那個答案。

fulfillmentTrackingInfoUpdate 的說明是「Updates tracking information for a fulfillment, including the carrier name, tracking numbers, and tracking URLs.」開啟 notifyCustomer 之後，「customers receive shipping update emails with tracking details and receive notifications about future updates to the fulfillment」；欄位不填則不會發出任何通知。客戶會不會知道這一次掃描，是流程必須刻意決定的事。
Shopify Admin GraphQL API — fulfillmentTrackingInfoUpdate
在 company 欄填入受支援的物流商名稱，Shopify 會自動生成追蹤網址。單件包裹用 number 同 url；多件包裹用 numbers 同 urls 陣列——所以拆成多件的一張訂單，是一次呼叫帶多個編號，不是多次呼叫。
Shopify Admin GraphQL API — fulfillmentTrackingInfoUpdate
DHL 追蹤的初始配額是「250 calls per day, with a maximum of 1 call every 5 seconds」，而文件本身形容它「intended for initial development and is not suitable for production use」；超出之後 API 回 429。幾百件在途包裹的每半小時輪詢，會在它成為一個真正在用的流程之前就先撞爆。
DHL API — Shipment Tracking (Unified)
各家物流商的批次上限不同，而批次上限決定你的輪詢設計。FedEx 文件寫明應該「Limit the number of tracking numbers in a single-track request to 30」——所以一千件在途出貨，每一輪、每一間物流商至少三十四次呼叫。
FedEx Developer Portal — Track API

什麼情況不值得做

以下三種情況，維護成本會高於人手複製的代價。

物流商本身已經把狀態寫回你的網店。既有整合已經存在的話，這個流程就是同一個欄位的第二個寫入者，兩者遲早會在客戶面前互相矛盾。
你每日只寄幾件貨，而且只用一間物流商。貼一個追蹤編號只需要幾秒；一個帶配額、帶物流商對應、帶通知規則的輪詢迴圈，不止幾秒。
未有人決定哪些狀態值得發通知。沒有這個決定，流程預設就是每一次掃描都通知，客戶於是學會略過你的物流郵件——那個代價，比從來沒有發過還要高。