網店與市集
一份商品資料，上架到各平台
同一件外套，在你眼中是一件商品，在四個渠道眼中是四份不同的文件：這邊標題要短，那邊要選它自己的分類樹，還有一個只有它才問的屬性欄。問題不在於重複輸入。問題在於每個渠道都慢慢變成自己那一套版本，最後沒有人講得出哪一個才對。做法是保留一份資料，再按渠道各自輸出。真正值得認真做的，是拒絕那一步：必填欄位未齊的渠道，不應該先上架再算。
- 觸發
- 兩個
- 執行頻率
- 每小時一次
- 工具
- 4 件
- 需要 durable execution
- 不需要
流程
上面那條負責保持一份乾淨的資料，下面那條定時按渠道輸出，只有能夠填得齊的渠道才會上架。
商品資料有改動
Sheets · Airtable
整理成統一格式
n8n · Make
寫入主資料行
Sheets · Airtable
每小時一次
n8n 排程
按渠道輸出
n8n
渠道欄位是否齊全？
n8n IF
上架到該渠道
Shopify Admin API
先扣起，講明欠什麼
Slack · WhatsApp
逐步拆解
- 01
商品資料有改動
Sheets · Airtable有人改了主表其中一行，可能是價錢、相片，或者一句規格。這是唯一容許編輯的地方。所有渠道都在它下游，渠道那邊不會反過來改回主表。
- 02
整理成統一格式
n8n · Make收成一個固定結構：標題、詳細描述、尺寸、材質、依固定次序排列的相片，以及每個渠道各自的分類值。縮短標題同對應分類都在這一步做一次，不要分散到四條分支入面做四次。
- 03
寫入主資料行
Sheets · Airtable把整理好的資料，同各渠道目前實際持有的版本並排存放。兩欄之間的差距就是這件事的核心。沒有這一欄，你分不出「改了但未上架」同「渠道靜靜地拒絕了」。
- 04
每小時一次
n8n 排程上架那一輪由計時器帶動，不是由每次編輯帶動。編輯本身是一陣一陣的，有人四分鐘內改十一行；計時器會把它收成每個渠道一次，而不是十一次。
- 05
按渠道輸出
n8n由主資料行為每個渠道砌一份 payload：它自己的標題長度、它自己的分類編號、它自己的屬性名稱。資料本身不會因渠道而不同，不同的只是輸出方式。
- 06
渠道欄位是否齊全？
n8n IF送出之前，先對照該渠道的必填要求檢查一次。在這裡發現缺一個屬性，代價很低；送出之後才發現，就是一個被退回的商品頁，或者更差——一個已經上架、但尺寸位置空白的頁面。
- 07
上架到該渠道
Shopify Admin API送出整份資料，而不是局部更新。整份送出，主資料行才真正有權威。但同一個做法亦代表：不完整的 payload 會抹走它沒有寫上的東西，所以檢查那一步要放在它前面，不能放在後面。
- 08
先扣起，講明欠什麼
Slack · WhatsApp寫明是哪件商品、哪個渠道、欠哪一個欄位。一句「上架失敗」只會逼人再入賣家中心，逐個對四十個屬性找出是哪一個，而那正是你想省掉的工序。
平台不容許的事
整份送出不是風格偏好，而是那個寫入動作本身的行為，後果亦寫在文件上。
productSet 的說明是「performs multiple operations to create or update products in a single request」；而對於清單型欄位——變體、系列、metafield——它會「Creates new entries, updates existing ones, and deletes omitted entries」。由不完整資料輸出的 payload，不會略過它沒有寫上的部分，而是把它刪掉。
Shopify Admin GraphQL API — productSet同一個 mutation 預設同步執行並回傳更新後的商品；傳入 synchronous: false 就會改為回傳一個 ProductSetOperation，狀態要自己輪詢。文件同時寫明「By default, stores have a limit of 2048 product variants for each product」——尺碼乘顏色的矩陣由程式生成之前，這條上限值得先知道。
Shopify Admin GraphQL API — productSet整個目錄一次過推送要用 bulk import：上傳一個 JSONL 檔，上限 100MB，每行一筆輸入。由 API 版本 2026-01 起，「each app can run up to five bulk mutation operations per shop simultaneously」；更早的版本每種類型同時只可以跑一個。結果檔需要驗證身分，並且一星期後失效——沒有人讀過的那一輪，等於要重跑一次。
Shopify — Bulk import data with GraphQL如果主資料放在 Airtable，讀取那一邊同樣有配額：「The API is limited to 5 requests per second per base」，同一個 token 全部流量上限為每秒 50 次，超出會回 429，而且「you will need to wait 30 seconds before subsequent requests will succeed」。逐行讀取的每小時一輪，會在網店察覺任何事之前先撞到這裡。
Airtable Web API — Rate limits
什麼情況不值得做
以下三種情況，維護成本會高於重複輸入的代價。
你只有幾十件商品，而且一季才改一次。一年人手輸出四次，比起養住一張對應表輕鬆——那張表每次渠道改分類名稱都要跟著改。
各渠道賣的本來就是不同商品。一邊賣套裝、一邊賣單件，那不是同一份資料的不同輸出方式；硬要塞進同一行，只會造出一層沒有人看得懂的轉換邏輯。
未有人拍板哪一個系統是主。這件事未定之前，流程不會消除大家對目錄的分歧，只會定時把其中一方的版本上架，而另一方繼續在下面改。