電商 API 串接是什麼？訂單、Webhook 與庫存同步流程
電商 API 串接是讓平台、ERP 與物流系統交換商品、訂單及庫存資料的方法。API 與 Webhook 各有用途，若沒有重送防呆及對帳，資料依然可能不同步。
「電商API串接」的重點不只是取得資料，還包含訂單去重、失敗重試及庫存狀態對帳，才能維持跨平台資料一致。
API 在電商營運扮演什麼角色
訂單成立後，平台可提供訂單編號、商品規格、數量與付款狀態供後台處理；ERP 完成出貨後，也可能將物流單號及貨態送回平台。實際可交換的欄位取決於平台開放範圍與權限。
如何避免重複訂單與重複扣庫
系統可能因逾時而重試相同請求。如果沒有以平台訂單 ID 識別，便可能建立兩次訂單。介接應設計冪等機制，確保同一事件重送不會重複扣減或出貨。
為什麼會有庫存同步延遲
更新有時需要排隊、等待平台回應，還可能遇到呼叫頻率限制。當訂單集中湧入，應有庫存保留、處理順序、失敗告警與重試流程；不能只以「每分鐘同步一次」評估整體風險。
測試不能只跑正常訂單
取消、拆單、部分退款、預購、物流取號失敗及商品停售都需測試。對每一種事件建立狀態對應表，並安排例外處理人員，讓失敗事件能回復而不被忽略。
如何衡量串接品質
觀察漏單率、重複匯入次數、同步異常恢復時間與庫存差異。若系統可記錄每次 API 操作及錯誤原因，日後查找問題會更有效率。
Webhook 如何與 API 搭配？
Webhook 是事件通知，不是完整資料庫
例如顧客在網店成立訂單，平台可發送 Webhook 告知後台有新事件，後台再透過 API 取得訂單細節、核對訂單 ID，建立或更新內部訂單。部分平台會重送事件，因此系統須能辨識已處理的事件，避免重複扣庫。
電商訂單同步流程示意
平台成立訂單 → Webhook 通知／排程查詢 → ERP 取得訂單資料 → 驗證 SKU 與狀態 → 保留庫存 → 倉庫出貨 → 透過 API 回寫物流編號與貨態。
這是典型流程示意，不代表每個平台都支援全部事件或欄位。若通知漏送，應透過定期對帳補齊；若 API 回傳錯誤，則要記錄失敗原因並重試。實際選型時可請 BunnyWork 示範目前已串接的 SHOPLINE 與蝦皮商品、訂單、庫存與物流整合。
API 與 Webhook 有什麼不同？
| 面向 | API | Webhook |
|---|---|---|
| 常見用途 | 主動查詢或更新完整資料 | 事件發生時通知 |
| 觸發方式 | 由請求端發起 | 由事件來源推送 |
| 需要注意 | 權限、呼叫限制、重試 | 重送、漏送、簽章驗證 |
SHOPLINE、蝦皮的 API 串接有什麼差異？
以 SHOPLINE 訂單建立為例，ERP 可依授權與串接範圍取得訂單，再處理 SKU 對應、庫存保留及物流回寫；蝦皮訂單也依同樣的流程進入後台。不同電商平台即使都提供 API，商品規格、訂單狀態與庫存欄位也不完全相同。建議依平台分開列出資料方向、更新頻率與權限，而不是只用「支援雙向同步」概括。
這篇最值得帶走的三個重點
- 電商 API 串接的品質不只在資料傳輸成功，更在重複事件防呆、錯誤重試及資料對帳。SHOPLINE 與蝦皮的欄位和訂單狀態需要分別對應。
- 導入前先用代表性的商品規格與異常訂單測試，確認實際作業是否支援。
- 追蹤異動紀錄與流程負責人，避免只靠人工重複整理表格。
延伸閱讀：多倉庫庫存管理、電商庫存管理重點，並可透過 BunnyWork 功能教學 了解商品、庫存、訂單與出貨的實際操作。
常見問題
Webhook 和 API 一樣嗎？
Webhook 是事件通知機制，常搭配 API 讀取完整資料。
有 API 就能接所有系統嗎？
還要考慮權限、平台限制、資料格式與開發成本。
電商API串接最先該檢查什麼？
先確認商品 SKU、作業狀態、資料責任來源及例外處理方式，並以真實營運案例核對結果。
