系統整合與 API 串接開發指南：需求、風險與驗收
「我們想把訂單自動帶進出貨系統」「希望會員在官網和門市是同一套」「能不能讓客人在 LINE 上查進度」——這些需求聽起來各不相同，本質上都是同一件事：系統整合。
整合專案有個特別的性質：它的難度不在你這邊。 技術上通常不複雜，但因為要跟別人的系統打交道，時程與風險的來源跟一般開發完全不同。
先用白話理解 API
API 可以想成兩套系統之間的服務窗口。你不需要走進別人家的機房翻資料，只要照對方規定的格式在窗口遞單，窗口就會把資料交給你，或代你完成一個動作，例如建立訂單、查詢庫存。
這個比喻可以延伸出幾個實務重點：
- 窗口有開放範圍。 對方願意開放查詢，不一定願意開放修改。很多整合卡住不是做不到，而是對方沒開這扇窗。
- 窗口有排隊規則。 多數服務會限制呼叫頻率，大量資料同步要分批處理。
- 窗口會有臨時狀況。 對方維護、改版、憑證到期，你的系統要能承受，而不是整個當掉。
理解這三點，你在跟廠商討論整合需求時，就能問出對的問題。
常見的整合需求類型
訂單流：把下單資料傳到出貨、倉儲或 ERP 系統，並把出貨狀態與物流單號回傳。這類整合的價值最直接，因為它取代的是每天固定發生的人工複製貼上。
庫存同步：多通路銷售時，庫存要在各通路之間保持一致。難點在同步的頻率與超賣的處理規則——完全即時的成本高，多數情況是在可接受的延遲與保留安全庫存之間取得平衡。
會員與點數：讓官網、門市、App 看到同一個會員。難點通常不是技術，而是先確定誰是那份資料的主檔，以及舊資料重複時怎麼合併。
金流與發票：付款、退款、發票開立與作廢。異常情境的處理比正常流程更重要，細節可參考電商網站開發指南。
CRM 與行銷工具：把顧客行為與名單送進客戶關係管理或行銷自動化工具。這類整合要特別注意個人資料的蒐集範圍與使用目的，相關規範請以主管機關的最新說明為準。
LINE 與通訊軟體：訂單通知、會員綁定、客服轉接。要留意平台的功能與規範會調整，實際可用範圍以官方最新文件為準。
App 與後端：App 本身就是靠 API 跟後端溝通，因此 App 專案幾乎必然包含介面設計工作，相關成本結構見App 開發費用完整指南。
三種常見的串接方式（白話版）
雖然都叫串接，實際做法有三種，成本與適用情境差很多：
即時呼叫：需要時馬上去問一次。例如顧客結帳當下查詢庫存。優點是資料最新，缺點是對方系統一慢、你的畫面就跟著慢，而且呼叫次數高容易碰到頻率限制。
定時批次：固定時間一次搬一批。例如每天凌晨同步商品資料。優點是穩定、對雙方負擔最小；缺點是資料有延遲，不適合會影響交易判斷的欄位。
事件通知：對方系統一有變動就主動通知你。例如付款完成後即時推送結果。優點是即時又不浪費呼叫次數，缺點是通知可能重複或遺漏，你的系統必須能處理同一則通知收到兩次的情況，也要有補查機制。
實務上一個專案常常三種都會用到：交易相關走事件通知並搭配補查、查詢型走即時呼叫、大量資料走批次。討論需求時先問廠商「這段打算用哪一種、為什麼」，比問「多久能做好」更能看出對方有沒有想清楚。
整合專案為什麼老是超時
一、對方的文件與實際行為不一致。 這是最常見的狀況。文件寫欄位必填、實際可以空白；文件寫回傳數字、實際回傳文字。解法只有一個：在報價與排程前先做實測，用真實的測試帳號打幾次，確認格式與錯誤訊息真的長那樣。
二、資料定義對不上。 同一個客戶在兩邊有不同編號、商品規格的單位不同、日期有沒有帶時區、金額含不含稅。這些看起來瑣碎，卻是整合最花時間的部分，而且錯了會直接變成帳務問題。
三、權限與資安流程要等。 申請正式環境金鑰、白名單設定、資安審查，這些都需要對方窗口配合。它們無法靠加派人力壓縮。
四、對方也在改版。 整合上線後，對方系統改版可能讓原本正常的串接失效。這是長期成本，不是一次性工作。
五、沒有人負責定義規則。 「訂單取消但已出貨怎麼辦」這類問題屬於業務決策，不是工程問題。沒有人拍板，開發就停在那裡。
事前盤點清單
在請廠商報價之前，把下面這些整理出來，會大幅降低估錯的機率：
系統清單：要串接的每一套系統名稱、版本、是自架還是雲端服務、由誰維護、有沒有現任窗口。
資料流向：每一筆資料從哪來、到哪去、單向還是雙向、誰是主檔。畫成一張圖比寫十頁文字有用。
頻率與量體：即時、每小時還是每天一次？一天大概幾筆、尖峰時段多少？
現有的人工流程：目前是誰在手動處理、用什麼檔案格式、每天花多久。這份資料同時是需求依據與日後的效益衡量基準。
文件與測試環境：對方有沒有技術文件、有沒有測試環境、申請要多久。
例外規則：退貨、取消、改單、部分出貨、缺貨。這些情境的處理方式要由你方決定。
負責人：對方系統的技術窗口是誰、回覆速度大概多快。這一項常常決定整個專案的節奏。
這份盤點不必由技術人員來寫。它問的都是業務問題：資料現在從哪來、誰在處理、處理多久、錯了誰負責。由最熟悉作業的同仁整理，比由外部廠商猜測準確得多，也能讓報價建立在真實條件上而不是假設上。
盤點完之後，還要做一件事：排出優先順序。不是所有整合都值得做。判斷基準有三個——這條串接每個月省下多少人工時間、出錯的後果有多嚴重、以及對方系統的配合度如何。把配合度低、效益又不明顯的項目往後放，通常比堅持一次做完更務實。
驗收與監控要看什麼
整合的驗收不能只測「正常情況會不會過」。至少要涵蓋：
異常情境測試：對方回傳錯誤、逾時、重複送出同一筆、傳到一半中斷。系統該重試、該記錄、還是該通知人工處理，都要有明確行為。
重複處理的防護：同一筆訂單被送兩次，不應該變成兩筆。這在金流與庫存上特別重要。
紀錄可查：每一次傳輸都要留下時間、內容與結果，出事時才查得到是誰、在哪一步出問題。
失敗要有人知道：最危險的不是失敗，而是靜靜地失敗。上線時就要設定失敗通知與負責的接收者。
定期對帳：兩邊的數量與金額定期比對。系統再穩，長期跑下來也會有落差，重點是及早發現。
上線後的責任歸屬要寫進維護合約，包含對方改版時由誰處理、回應時間怎麼算，這部分見網站維護費用包含什麼。
什麼時候該先找顧問，而不是直接開發
如果你的情況是「知道很多事要串，但不確定該從哪一條開始」，那第一步不該是找人寫程式。
整合需求往往牽涉多套系統與多個部門，先做一次現況盤點與優先順序排列，比一次全做更省。NETVANA 的軟體顧問服務（包含技術架構審查、技術選型評估與 CTO-as-a-Service 兼任技術長）交付的是技術評估報告、架構建議文件與優先順序路線圖，用途正是幫你在動工前把「先做什麼、後做什麼、哪些其實不用做」講清楚。要自建團隊還是找外部協助，取捨見軟體外包 vs 自建團隊。
若你要串接的是一套沒人敢動的舊系統，問題的層級會更高一階，處理方式見舊系統現代化指南。
系統整合的成敗，大多在動工之前就已經決定：資料定義有沒有對齊、對方窗口回不回得動、例外規則有沒有人拍板。程式只是把這些決定寫下來而已。
如果你手上有幾套系統想打通、但還不確定該從哪裡下手，與 NETVANA 聊聊你的整合需求。我們會先盤點現況與資料流向再談方案，軟體服務採先諮詢再報價，服務內容見軟體服務介紹。
延伸閱讀：電商場景的串接重點，見電商網站開發指南；老舊系統的汰換策略，見舊系統現代化指南；評估廠商時該問的問題，見如何挑選軟體開發公司；串好資料之後，才有條件談 AI 應用，可以看企業導入 AI 功能指南；整合出來的資料，通常需要一個內部後台來用，可以看內部後台系統開發指南；整合案最難的是驗收，缺陷分級要先講好，可以看軟體驗收與 UAT 測試指南；發票串接是最典型的外部 API 驗收案例，可以看台灣電子發票串接指南；物流回傳的非同步狀態，是串接最容易出錯的地方，可以看物流串接完整指南；身分驗證類串接有自己一套授權流程要走，可以看第三方登入與 SSO 指南；簽核結果要串進人資財務，整合風險不能忽略，可以看電子表單與簽核流程系統。
