API 串接是什麼？什麼情況需要

API 是系統之間的溝通管道

簡單說，API 是兩套系統交換資料的約定方式。網站要跟其他系統對話——把訂單傳給 ERP、從 POS 取得庫存、請物流商建立託運單——就需要透過對方提供的 API。

沒有串接也能運作，靠人工把資料從一邊複製到另一邊。串接的價值就在於省下這段人力，並減少人為錯誤。

常見的串接場景

金流與物流的串接見金流串接是什麼，那是最常見也最標準化的一類。

什麼情況值得串接

判斷標準是省下的人力與減少的錯誤，是否超過建置與維護成本。

值得做

• 資料量大且頻繁——每天要人工搬移幾十筆以上
• 錯誤代價高——庫存或價格輸錯會造成實際損失
• 時效要求高——客戶下單後要立即反映
• 已經有人專職在做複製貼上的工作

先不必做

• 資料量小——一天幾筆，人工處理反而快
• 規則還在變動——流程沒穩定就串接，會反覆修改
• 只是覺得「自動化比較先進」——這是最常見的浪費
• 對方系統即將更換——串了也白串

先評估有沒有更簡單的做法

串接不是唯一選項。在投入之前，可以考慮：

• 匯出匯入——用試算表定期批次處理。成本極低，適合每天或每週一次的情境
• 通知即可——只是要讓某人知道有新訂單，寄信或推播就夠了
• 使用現成的整合工具——部分服務之間已有現成的連接方案，不需客製開發

「先用匯出匯入撐一段時間，確認流程穩定再串接」 是很務實的做法，也能讓你更清楚真正需要同步的是哪些欄位。

串接的方向

規劃時要先確認資料流的方向，這直接影響複雜度：

• 單向送出——網站把訂單傳給 ERP。最單純
• 單向取得——網站從 ERP 取得庫存與價格。次之
• 雙向同步——兩邊都可能異動，需要處理衝突。複雜度明顯較高

雙向同步一定要先回答一個問題：同一筆資料兩邊都改了，以誰為準？ 見資料同步該怎麼設計。

不是所有系統都能串

這是評估的第一關。有些系統：

• 根本沒有提供 API
• 有 API 但功能有限，做不到你要的事
• 需要額外付費才開放
• 只提供給特定合作夥伴
• 是很舊的系統，沒有文件也沒有人維護

在報價之前，必須先確認對方端的可行性。 這一步沒做，後面的估算都不可靠，見串接前要確認什麼。