服務內容

服務介紹|第三方 API 與系統整合:新網站或新 App 該如何接上你既有的 ERP、金流、物流、CRM

2026.05.20 · 25 次瀏覽
服務介紹|第三方 API 與系統整合:新網站或新 App 該如何接上你既有的 ERP、金流、物流、CRM

決定一套新系統能不能撐過第三個月的,從來不是介面好不好看,而是它能不能乾淨地跟你既有的四五套系統對話——這篇分成五個階段把流程講清楚

客戶第一天看到的交付物是一個新網站、新 App、或新的內部系統。決定一年後客戶開不開心的交付物,很少是那個新系統本身——是那個新系統能不能乾淨地跟客戶原本就在跑的四五套系統對話。ERP、金流、物流、會計、CRM、電子發票、客服系統。整合做對,新系統用起來毫不費力;整合做錯,新系統會變成額外工作,UI 再漂亮也沒用。


我們的「第三方 API 與系統整合」服務就是為了這個落差存在。下面是我們陪每位客戶走過的完整流程,分成五個階段,每個階段都標明交付物與決策點。


第一階段:整合需求盤點(第 1 週)


在動任何 code 之前,我們會坐下來跟客戶把這個新產品需要讀、需要寫的每一套外部系統盤點一遍。盤點不只 ERP 和金流。我們會問:


  • 所有保存「客戶資料」的系統(CRM、MailChimp、Klaviyo、LINE@)。
  • 所有保存「交易資料」的系統(POS、ERP、會計軟體、電子發票平台)。
  • 所有保存「營運資料」的系統(倉儲、物流、貨運 API)。
  • 所有保存「溝通紀錄」的系統(客服系統、內部聊天、簡訊 gateway)。

每一套系統,我們會記錄:credentials 由誰保管、rate limit 是多少、有沒有 sandbox、認證模型(OAuth、API key、mTLS)、預期的資料格式是什麼。交付物是一張「整合地圖」——一頁讓客戶看清楚所有要接的線。


第二階段:資料流向與衝突解決(第 2 週)


整合裡最難的問題很少是技術問題,是:當兩套系統對同一個客戶或同一張訂單意見不同時,誰贏?我們會跟客戶把每一個共享 entity 的「真實來源」決定清楚。常見模式:


  • ERP 是庫存的真實來源,新站只是 follower:庫存變動只從 ERP 單向同步出去。
  • 新站是客戶資料的真實來源,ERP 同步進來:客戶會看到的 UI,就活在那個客戶實際使用的位置。
  • 雙向且帶衝突解決:訂單兩邊都能改,但規則是「最新時間戳贏,配 audit log」。雙向比較貴,只在業務真的需要時推薦。

交付物是「真實來源矩陣」——這份文件會變成工程團隊往下開發的規格。


第三階段:Adapter 層建置(第 3 至 5 週)


我們不會把整合 code 直接寫進業務邏輯。每一套外部系統都會有自己的 adapter——一個小模組,負責把外部系統的詞彙翻譯成新系統的領域模型。這個隔離讓客戶拿到四個好處:


  • ERP 供應商換 API 版本(他們總是會換),只改 adapter。
  • 貨運從 XML 換 JSON,只改 adapter。
  • 新業務規則要「同一張單同時送 A 物流與 B 物流」,adapter 模式可以乾淨地處理 fan-out。
  • 要換掉一家供應商,adapter 是可替換單元,而不是整個後端。

標準技術堆疊:Laravel queue 跑非同步、Redis 做 rate-limit 協調、一張獨立的 integration_logs 表索引在 (adapter, direction, timestamp),每一次呼叫都可稽核。


第四階段:失敗情境設計(第 6 週)


整合 code 在 happy path 上跑得起來,那是容易的一半。另外一半是:外部系統當機、變慢、回傳垃圾的時候會怎樣。我們的標準失敗情境協定涵蓋四種:


  1. 外部系統當機:把請求排進 queue、指數退避重試、第三次失敗時通知維運。
  2. 外部系統很慢:在保守門檻 timeout(預設 8 秒),不讓新系統面向使用者的請求被卡住。
  3. 外部系統回傳非預期資料:在 adapter schema 做驗證、把壞 payload 記錄起來、在後台呈現人讀得懂的錯誤、絕不靜默崩潰。
  4. 兩套系統在飛行中意見不同:用第二階段的真實來源矩陣做決定性的解決、把解決方式寫進稽核軌跡。

第五階段:切換、對帳、與上線後三十天(第 7 至 8 週)


切換很少是「按一個鍵」的瞬間。我們會讓整合在影子模式下平行跑兩週——新系統同時寫入自己的資料庫與外部系統,而客戶原本的系統也持續在寫。每日對帳報告會把任何 drift 顯出來。連續五天對帳乾淨,我們才把舊系統下線。


上線後交付:


  • 一個即時整合儀表板(uptime、error rate、每個 adapter 的 queue 深度)。
  • 每月一次整合健檢報告——哪些 API 不穩、哪些需要跟供應商重新談。
  • 每季一次真實來源矩陣回顧,跟著客戶業務演進。

注意事項:每位客戶我們事前都會講的三件事


第一,「每套系統都有 API」是個迷思。有些系統沒 API、有些有但沒文件、有些有 API 但生產環境根本不能用。我們在承諾之前先做可行性。第二,整合專案幾乎一定會揭露客戶既有資料比他們以為的還髒。我們在每份整合報價裡都會排一條「資料清理」項目。第三,整合的維護成本永遠不會歸零。API 會變、憑證會過期、rate limit 會調整。年度整合維護費通常落在原始整合費用的 15–25%。沒留這筆預算的客戶,整合會在 18 個月內壞掉。


整合不是一次性專案,是一套紀律。我們服務五年以上的客戶,就是那些「整合地圖」我們今天還在持續更新的客戶。