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