委託 API 串接開發前，你要先跟金流商和系統開發公司確認的 5 件規格
收到設計公司的報價信，信裡問你「金流要串哪家、ERP 是哪套、有沒有 API 文件」，你盯著這幾個名詞，不確定是要回答、還是要反問。先把一件事講清楚：對方要你確認的，不是叫你會寫程式，是要你把「要串的那個服務」的規格說清楚。這就是 API 串接開發在做的事——把你的網站或後台，跟另一個現成的服務（金流、物流、ERP）接起來，讓資料自己流動，而不是有人手動搬。
你要付錢買的是這個「接」的工程，不是那個服務本身。所以回信之前，真正該先問清楚的不是價錢，是五件規格：對方的 API 文件是不是最新版本、認證要用哪一種、每分鐘能呼叫幾次、有沒有能先測的沙盒環境、出錯的時候系統怎麼接。這五件沒確認，任何一家系統開發公司給你的 API 串接開發報價和時程，都是先喊一個數字、做下去再說。下面逐件拆開，每一件都寫「它是什麼、為什麼回信前要先問、不問會卡在哪」。
API 串接開發到底在串什麼：你要付錢買的是哪件事
先把名詞分開。「自己寫程式」是從零做一個功能；API 串接開發是把兩個已經存在的系統對接起來——你的訂單系統這一端，和金流、物流、ERP 那一端。中間那條接線怎麼接、接得牢不牢，就是你要發包的工程。難度不在你這邊，在「對方那個服務開放了什麼」：文件齊全就接得快，文件零散或是舊的，同一條線就要反覆試。
舉一個設想的例子。一家賣進口香料的網路選物店，老闆想在官網串金流，讓客人刷卡後訂單自動成立。他原本以為難的是「寫刷卡功能」，追問之後才發現，難的是金流商那端有三種串接方式、文件分散在兩個網站，廠商得先搞懂該走哪一種。他要付的錢，多在這段「搞懂對方怎麼接」，不在刷卡本身。知道這一點，他回信時問的就不再是「多少錢」，而是「你評估過對方的 API 文件了嗎」。
先要 API 文件、而且要問它是不是最新版本
你問「該去跟金流商要什麼」，答案的第一項就是 API 文件。這份文件是那個服務寫給開發方看的說明書——有哪些功能可以串、每個功能要傳什麼、會回什麼。沒有它，廠商等於閉著眼睛接線。
關鍵不只是「有沒有文件」，是「這份文件是不是對應你要用的那個版本」。同一個服務常常同時存在舊版和新版，文件也有兩套。拿到舊版文件去接新版服務，接到一半才發現對不上，時程就從這裡開始跑掉。
舉一個設想的例子。一家做手作皮件的電商，要把訂單同步到一套物流系統。委外的那一家照著網路上搜到的文件開工，做到測試階段才發現那份是兩年前的舊版，物流商年初已經改版、欄位都不一樣，前面兩週幾乎白做。問題不在廠商不努力，在開工前沒有人向物流商要「現在正式在用的那一版」文件。所以你回信可以加一句：請對方確認拿到的是服務商現行版本的文件，不是搜尋引擎上找到的那份。
認證機制用哪一種，決定你要先去申請什麼
接線之前，對方的服務要先確認「來敲門的是你，不是別人」，這就是認證機制。常見的差別在於：有的只要一組金鑰，有的要走一套授權流程、你得先在對方後台申請一組憑證。
這一關為什麼回信前就要問——因為申請憑證這件事，往往卡在你身上，不在廠商身上。廠商可以把程式寫好，但那組金鑰或憑證得用你公司的名義去申請，有的還要審核幾個工作天。你不先動手，程式寫完了也上不了線。
舉一個設想的例子。一家賣戶外露營裝備的選物店，要串接金流系統收款。廠商兩週就把串接做完了，結果卡在金流商的商家認證——那要店家本人備齊營業登記去申請，審核又花了十天。整個專案的時程，最後是被這十天拖住，不是被寫程式拖住。老闆事後才懂，當初回信時就該問清楚：認證要用哪一種、哪些是需要我這邊先去申請的。把這件事提前，時程表才排得準。
速率限制與沙盒環境：旺季會不會爆、上線前能不能測
這兩件放在一起講，因為它們共同決定你簽約之後會不會在上線時被卡。速率限制是對方服務「每分鐘、每天最多讓你呼叫幾次」的上限：平常用不到，但你一檔活動流量衝上來、訂單同時湧進，呼叫次數撞到上限，後面的訂單就會卡住或失敗。沙盒環境則是對方提供的「測試用的場」，讓廠商在不碰真實金流、不真的扣款的情況下，把各種情況先跑過一遍；沒有沙盒，就只能拿正式環境測，等於上線那天才第一次真的跑。
舉一個設想的例子。一家做節慶禮盒的網路選物店，平常訂單平穩，廠商也測得順。到了過年前的檔期，一天的訂單量是平常的幾十倍，串接金流系統的呼叫次數瞬間撞上限，有一段時間客人刷卡一直失敗。追查後發現，當初沒人問過金流商的速率上限是多少、旺季要不要先申請調高，也沒有一個能模擬尖峰的沙盒環境可以壓測。這不是廠商程式寫壞了，是「旺季的量」從頭到尾沒被放進需求裡。所以你回信時值得問兩句：對方的速率上限是多少、旺季能不能調；有沒有沙盒環境可以在上線前把尖峰情況測過。
錯誤處理規格：出錯時系統怎麼接，才不會變成你自己收爛攤
串接一定會有出錯的時候——客人網路斷了、對方服務剛好在維護、同一筆訂單被送了兩次。錯誤處理規格講的就是「這些情況發生時，系統該怎麼接」：是自動重試、是擋下來提醒、還是留一筆紀錄等人工處理。它最容易在報價階段被跳過，因為不像「做一個刷卡功能」那樣看得見；可是沒寫進需求，出錯時就沒人負責，最後往往是你自己在對帳時收爛攤。
舉一個設想的例子。一家賣寵物鮮食的電商，串接金流系統時只談了「刷卡成功要怎樣」，沒談「刷卡到一半斷線怎麼辦」。上線後遇到客人付了款、但訂單那邊沒收到成功通知，變成錢進了、單沒成立，老闆每週得自己比對帳單、手動補單。問題不在廠商沒本事處理這種情況，在當初的需求和系統開發報價裡，根本沒把「出錯怎麼接」這一項算進去。你回信時可以直接問：訂單送到一半失敗、重複送出、對方服務沒回應，這幾種情況系統會怎麼處理。
把這五件寫進需求，再回那封信
回到你信箱裡那封信。對方問你金流要串哪家、ERP 是哪套、有沒有 API 文件，與其急著回一個「大概多少錢、多久能好」，不如把這五件先確認清楚：文件是不是現行版本、認證要用哪一種又有哪些得你先申請、速率上限和旺季調整、有沒有沙盒環境、出錯時怎麼接。這五件有了答案，系統開發委外的報價和時程才有對照的基準，你也才看得懂不同系統開發公司報的到底是不是同一件事。
你不需要會寫程式，也不需要看得懂每一行技術細節。委託 API 串接開發這件事，你要守住的是「把要串的那個服務的規格問清楚」——這一步做足，簽約之後被卡住的機率就少一大半。官網的 App 與系統開發服務頁有更完整的拆解，想把需求理清楚再發包，可以從那裡開始。