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