API 串接的費用與時程怎麼估？

為什麼串接的報價差異這麼大

同樣說「串接 ERP」，報價可能從數萬到數十萬。差異不是廠商亂喊，而是實際的工作量真的差很多。

理解影響因素，才能判斷報價是否合理。

影響成本的七個因素

其中「對方的成熟度」影響最大。串接一個文件完整、有測試環境的知名服務，工作量可能只有串接一套沒有文件的舊系統的幾分之一。

報價應該包含什麼

完整的串接報價通常涵蓋：

1. 可行性評估與規格確認——有些廠商會單獨計價，這是合理的
2. 開發——依動作數量與複雜度
3. 測試——含各種例外情況的測試
4. 上線與轉換——既有資料的初次同步
5. 文件與教學——後台如何操作、出錯如何判斷

其中第三項的工時常被低估。串接的測試比一般功能複雜得多——要測正常流程，也要測對方無回應、回傳錯誤、資料不符等各種狀況。

持續性成本

這是評估時最容易漏掉的：

• 對方服務的費用——月費、按次計費
• 維護費用——對方改版時需要調整
• 監控成本——確認同步是否正常運作

API 串接不是做完就結束的功能。 對方隨時可能改版、調整規格、或停止支援舊版本，屆時網站端必須配合更新，見串接的維護與常見問題。

時程為什麼容易延誤

串接是網站專案中最容易延期的項目，原因幾乎都在網站端以外：

一、申請與開通的時間不可控

對方的審核流程可能需要數週，而且可能來回補件。這段時間完全不在開發端的控制範圍。

建議在專案一開始就啟動申請，與網站開發平行進行。

二、文件與實際不符

很常見的情況：文件寫的欄位與實際回傳的不同、或文件是舊版的。這需要來回測試與確認，時間難以事先估算。

三、對方端的技術窗口回應慢

遇到問題需要對方協助時，回應速度不是你能決定的。

四、需求在過程中才釐清

開始串接後才發現「原來這個欄位對不起來」「原來還要處理退貨的情況」。這是規格沒有先確認清楚的結果。

降低風險的四個做法

1. 先做可行性評估再報價——不要用猜的
2. 提早啟動對方端的申請
3. 分階段進行——先做最核心的一兩個動作，確認可行再擴充
4. 在合約中約定對方端因素造成的時程順延

第四項很重要。如果延誤的原因是對方審核太慢或文件有誤，那不該由開發端承擔罰則。 合約中應有相應的順延機制，見付款方式與延遲處理。

分階段的建議做法

與其一次串接十個動作，不如：

• 第一階段——最有價值的一兩個動作，例如訂單送出
• 觀察一段時間——確認穩定、確認真的省下人力
• 第二階段——再擴充其他動作

好處是：投入可控、風險可控，而且第一階段跑過之後，你會更清楚後續真正需要什麼。

常見的情況是：原本以為需要十個動作，實際運作後發現有三個根本用不到。

一個判斷報價合理性的方法

請廠商說明報價是依據哪些動作、哪些工作項目。願意逐項說明的，通常是真的評估過；只給一個總價而說不出組成的，多半是估的。

報價單的看法見網站架設費用怎麼算。