四項關鍵能力
Section titled “四項關鍵能力”| 能力 | 意義 | 為何產品會因缺乏而停滯 |
|---|---|---|
| 即時價格與可訂房狀態 | 每個日期範圍的當前價格與實際可訂房狀態 | 快取價格在確認時會失效，破壞信任 |
| 訂房建立 | 建立飯店能收到的真實訂房 | 沒有此功能你只是轉介連結，不是產品 |
| 付款 | 在訂房流程中收款 | 轉到其他網站會導致轉換率下降 |
| 確認與 webhook | 通知旅客、飯店與系統訂房狀態 | 否則無法支援負載與對帳差異 |
大多數開發者找到的「飯店 API」涵蓋前兩項，有時只有第一項。交易是最困難的部分，也是決定你是否擁有產品的關鍵。
你整合的是誰的供應？
Section titled “你整合的是誰的供應？”這個問題決定後續一切。透過多層轉售的供應價格含加價，且可訂房狀態較不即時，且無法直接向飯店查詢訂房問題。直接來自飯店的供應則帶有飯店自訂價格、即時可訂房狀態，且飯店知道訂房存在。
對於旅客會與飯店官網比較的情況（大多數情況），飯店控管的供應避免價格較差的尷尬時刻。
若自行建立飯店訂房，成為商戶代表需承擔付款責任、拒付、退款、稅務處理，且通常需在各市場取得旅行社執照。
在 Wink，飯店仍是商戶，付款由飯店收取，整合者不需承擔這些責任。若合作夥伴確實需要自行收款，API 整合可提供商戶方案，但該方案有其授權要求。
三種整合層級
Section titled “三種整合層級”- 網頁元件。 將可訂房搜尋、房型列表或結帳元件放入現有頁面。無需後端工作；對版面控制最少。
- REST API。 完整控制搜尋、價格、訂房建立與確認，使用 OAuth2 認證。當訂房流程是產品體驗一部分時使用。
- MCP 伺服器。 為 AI 代理提供相同功能，助理可搜尋、報價並完成訂房，而非將使用者導向網站。
三者非互斥，產品常用元件作為行銷介面，API 作為核心流程。
- 先做一個城市、一個日期範圍的搜尋與報價。 先取得真實價格再設計其他。
- 建立一筆測試訂房，從頭到尾完成，包含付款與確認。
- 在建立 UI 前先訂閱
booking.create與取消事件。 - 早期決定歸因模型 — 來源資訊需隨訂房傳遞，否則報告後續只能猜測。
- 處理失敗狀況：報價與訂房間可訂房狀態消失、付款被拒、部分退款。
開發者應知價格
Section titled “開發者應知價格”Consumer 與 Booking Engine API 免費。Partner API 每月含 10,000 晚免費額度，超出後按單位計費。確認訂房需支付飯店 1.5% 平台費及成本卡片手續費，且當你的產品促成訂房時，適用10% 預設佣金，這是整合者的收益來源。
- 使用快取價格。 開發時看起來正常，生產環境會失敗。
- 付款交由重定向。 每次轉交都會流失訂房。
- 忽略 webhook 直到上線。 對帳變成人工工作。
- 不必要地成為商戶。 這是授權與責任決定，不只是技術問題。
- 不傳遞來源資訊。 後續無法重建歸因。