Shopify
商品 · 市場 · 訂單 · 客戶
CATALOG
商品與發佈
Product→Variant / Media→Catalog
渠道與市場可見性由 Catalog / Publication 控制，不是創建商品後自動全渠道展示。按 Shopify 對象建模
不是同步四張表，而是處理四組對象
Shopify 把商品、庫存、履約和客戶數據拆成不同對象與權限。先確認誰能寫、寫到哪個對象、發生衝突時誰優先，才不會覆蓋數據或重復履約。
帶著系統清單溝通 ↗INVENTORY
庫存與地點
InventoryItem×Location→InventoryLevel
外部系統可調整 available 等數量；訂單佔用的 committed 狀態由 Shopify 管理。FULFILLMENT
訂單與履約
Order→FulfillmentOrder→Fulfillment / Return
一個訂單可能拆成多個配送組或履約單，不能只按訂單號假設一次發貨。PRIVACY
客戶與隱私
Customer→Consent→CRM / Marketing
讀取客戶或訂單數據需要相應 scope；公開應用還必須處理查詢與刪除類合規 Webhook。連接路徑
平台不同，連接策略也不同
不為了“全都能接”而堆工具。能用官方渠道就優先官方渠道，需要跨平台集中管理再使用連接器，業務規則無法表達時才進入訂製接口。
銷售渠道與 Markets
先區分“引流到官網”和“渠道內下單”
Google、Meta 等引流型渠道要求實施頁商品與價格保持一致；TikTok Shop 等下單型渠道可按 Channel Market 配置獨立目錄、可售範圍、價格與幣種。
Google · YouTube · Meta · TikTok Shop
Sales Channels + Markets↗
Marketplace
Marketplace Connect 解決發佈，不替代平台規則
Shopify 官方 Marketplace Connect 可向 Amazon、Walmart 等平台發佈商品並集中處理訂單；賬號資格、Listing 欄位、幣種、配送和退貨仍需逐平台核對。
Amazon · eBay · Walmart
Marketplace Connect / App↗
營運與業務系統
ERP、WMS、CRM 接入前，先指定每類數據的主系統
庫存按 InventoryItem × Location 對應 InventoryLevel；訂單按 FulfillmentOrder 回傳履約；客戶數據按授權範圍、同意狀態和隱私刪除請求處理。
ERP · PIM · WMS · 3PL · CRM · BI
GraphQL Admin API + Webhooks↗
ProductVariantMediaMarket
OrderFulfillmentRefund
ConsentEventAttribution
以 Shopify 官方約束為設計輸入
對象、權限和事件機制，決定集成能否穩定運行
連接器的 Logo 只能說明“可能支援”。真正需要核對的是 Shopify 對象模型、應用訪問範圍、GraphQL 查詢成本，以及 Webhook 的重復、亂序和漏失處理。
- 對象邊界Product / Variant / Catalog、InventoryLevel / Location、Order / FulfillmentOrder 分別映射
- 權限與容量採用最小 access scopes；GraphQL 按查詢成本限流，單次查詢成本上限為 1,000 點，數組輸入最多 250 項
- 事件與恢復校驗 HMAC、用 Webhook ID 去重；按時間戳處理亂序，並定期通過 API 對賬補漏
Webhook 不是數據庫鏡像：Shopify 不保證事件順序，也建議用定期 reconciliation 對賬。接口設計必須包含冪等、重試、補數和人工兜底。
實施路徑
三步把“能連接”變成“能長期運行”
01
列出對象與主系統
逐項確認商品、庫存地點、訂單履約和客戶數據由誰創建、誰能修改。
02
驗證權限、容量與異常
測試 access scopes、查詢成本、批量邊界、狀態映射、重復事件和失敗回退。
03
建立對賬與版本機制
監控 Webhook、定時補數、保留人工重放入口，並按穩定 API 版本持續升級。