API 串接前要確認什麼？可行性評估清單

可行性評估比報價更重要

API 串接的專案最容易失敗的原因，不是網站端做不出來，而是對方端的條件與預期不符——沒有需要的功能、沒有文件、沒有測試環境、或根本聯絡不到人。

這些都是報價前就該確認的事。以下是一份可以直接拿去問的清單。

一、對方端的基本條件

1. 有沒有提供 API？ 是公開的，還是需要申請
2. 有沒有技術文件？ 文件是否完整、是否為最新版
3. 有沒有測試環境？ 這一項很關鍵，見下方說明
4. 需要什麼資格才能申請？ 是否須為特定等級的客戶或付費方案
5. 有沒有額外費用？ 開通費、月費、按次計費
6. 有沒有技術窗口？ 出問題時找得到人嗎

測試環境為什麼重要

沒有測試環境，就只能用正式資料測試——這代表測試過程可能產生真實的訂單、真實的扣款、真實的出貨。

如果對方沒有提供，要先討論替代方案，並把風險納入評估。

二、功能面的確認

• 需要的每一個動作，API 都支援嗎？ 例如「查詢庫存」有，但「更新庫存」可能沒有
• 資料欄位夠嗎？ 你要的欄位對方是否提供
• 有沒有呼叫頻率的限制？ 每分鐘或每日的上限是多少
• 單次可以處理多少筆？ 大量資料是否需要分批
• 回應速度如何？ 太慢會影響網站的使用體驗

頻率限制是最常被忽略的一項。 如果限制是每分鐘幾次，而你有上千筆商品需要同步，那就不能即時處理，必須改成排程分批。這會直接影響架構設計。

三、把需求寫成具體的清單

「跟 ERP 串接」這句話無法報價。要拆解成具體的動作：

這張表就是報價與驗收的依據。 沒有它，報價只能是估算，驗收也沒有標準。

四、資料對應的落差

兩套系統的資料結構幾乎不會完全一致，需要事先確認：

• 編號規則是否一致——網站的商品編號與 ERP 的料號能對得起來嗎
• 規格與選項的表達方式——一邊用單一料號，一邊用「商品加規格」的結構
• 價格——含稅或未稅、幣別、是否有多組價格
• 分類架構——兩邊的分類方式不同時怎麼對應
• 必填欄位——一邊必填但另一邊可能沒有這個資料

這一段的落差越大，開發成本越高。 有時候調整其中一邊的資料規則，會比寫複雜的轉換邏輯划算得多。

五、誰負責對方端

這是責任邊界的問題，務必在發包時講清楚：

• 對方端的設定、開通、參數提供，由誰負責溝通？
• 對方端如果需要客製調整，費用由誰承擔？
• 對方端出問題時，網頁設計公司的責任到哪裡？

常見的合理安排是：網站端由網頁設計公司負責，對方端由業主協調，雙方技術窗口直接對話。

若期待網頁設計公司代為處理對方端的所有溝通，應該事先說明並反映在報價中。

六、資安面

• 金鑰或憑證怎麼取得與保管？ 絕不可以放在前端程式碼中
• 會傳輸哪些資料？ 若含個人資料，雙方都要符合保護義務
• 連線是否加密？
• 是否需要限制來源位址？

個資的處理原則見會員資料與個資保護。

評估的產出

做完上述確認，你應該能得到：

• 一份具體的串接動作清單
• 對方端的文件與測試環境資訊
• 已知的限制（頻率、欄位、功能）
• 資料對應的落差與處理方式
• 雙方的責任邊界

有了這些，報價才會準確，時程才有依據。