四项关键能力
Section titled “四项关键能力”| 能力 | 含义 | 产品缺失时的影响 |
|---|---|---|
| 实时价格和可用性 | 当前价格和实际可预订的日期范围 | 缓存价格在确认时失效，破坏信任 |
| 预订创建 | 创建酒店实际收到的预订 | 没有它你只是一个推荐链接，不是产品 |
| 支付 | 作为预订的一部分收款 | 跳转到其他网站会导致转化流失 |
| 确认和 webhook | 告知客人、酒店和系统预订结果 | 否则支持负担和对账差距 |
大多数开发者找到的“酒店 API”覆盖第一项，有时覆盖第二项。交易是难点，也是决定你是否拥有产品的关键。
你集成的是谁的供应？
Section titled “你集成的是谁的供应？”这个问题决定了后续一切。通过链条转售的供应价格中包含加价，且可用性较旧，且无法直接向酒店查询预订问题。直接来自酒店的供应带有酒店自身价格、实时可用性，且酒店知道预订存在。
对于旅客会与酒店官网比较的任何情况——也就是大多数情况——酒店控制的供应避免了价格更差的尴尬时刻。
如果你自己构建酒店预订，成为商户意味着承担支付责任、拒付、退款、税务处理，且通常需要在每个市场持有旅行社执照。
在 Wink 上，酒店保持商户身份，支付由酒店收取，因此集成方无需承担这部分责任。对于确实需要自行收款的 API 集成，提供商户身份安排，但该方式有其自身的许可要求。
三种集成层级
Section titled “三种集成层级”- Web 组件。 在现有页面中嵌入可预订的搜索、房型列表或结账。无需后端工作；对布局控制最少。
- REST API。 完全控制搜索、价格、预订创建和确认，使用 OAuth2 认证。当预订流程是你产品自身体验的一部分时使用。
- MCP 服务器。 向 AI 代理开放相同功能，助理可以搜索、定价并完成预订，而不是将用户转到网站。
三者并不互斥——产品通常用组件做营销界面，用 API 做核心流程。
- 针对一个城市和一个日期范围进行搜索和定价。 在设计任何东西之前先获取真实价格。
- 端到端创建一个测试预订，包括支付和确认。
- 在构建任何 UI 之前订阅
booking.create和取消事件。 - 尽早确定归因模型——预订需携带来源上下文，否则后续报告只能猜测。
- 处理失败情况：报价到预订间可用性丢失、支付被拒、部分退款。
开发者应知的定价
Section titled “开发者应知的定价”Consumer 和 Booking Engine API 免费。Partner API 每月包含 10,000 晚免费额度，超出按单位计费。确认预订收取酒店 1.5% 平台费加成本价的卡片处理费，且当你的产品促成预订时，默认收取 10% 佣金——这就是集成方的收益来源。
- 基于缓存价格构建。 开发时看起来没问题，生产时失败。
- 将支付留给跳转。 每次跳转都会流失预订。
- 忽视 webhook 直到上线。 对账变成手工工作。
- 不必要地成为商户。 这是许可和责任的决策，不仅是技术问题。
- 不传递来源上下文。 归因无法事后重建。