初次对接酒店API分销接口必看

行业现状：

首先酒店资源分单体酒店和品牌连锁酒店，全国来说，肯定是单体酒店占据绝大多数，酒店资源不像 火车票有12306统一管理，机票有航司和中航信统一管理，酒店资源都是分散的，大多都在成千上万的代理手上，即使像携程这类 OTA巨头平台上，直签酒店也是占少数，绝大多少都是代理人投放的，这也是为什么 大家经常在不同平台看到的酒店价格相差甚远的元，就是酒店资源分散，没有统一管理机构，掌握在成千上万的代理人手上，且一个酒店一般存在多个代理人，同时代理资源除了投放在OTA平台上，一般也会被投放到各个分销平台上。

对接方案：
基于行业现状和酒店资源分散，中小微平台想对接全国酒店，且做到覆盖率90%以上，只有两种方案：

方案一：对接OTA（如携程，同程，美团等）平台，优点：覆盖率高，数据信息全（如房型图片等），售后有保障，缺点：对接门槛高，如同程就需要5万质保金对应5万间夜量要求，携程，美团目前已经关闭对外分销通道了；

方案二：对接多个酒店垂直B2B分销平台，因为每家资源优势和酒店数量都不一样，想要全国覆盖且价格相对有优势，只能尽可能多的对接多个平台 优点：单个门槛相对OTA较低，但缺点也很明显：就是麻烦，工作量大，需要对接n多个平台

基于方案一和方案二的优缺点，小编推荐可以对接已经把方案二实现的第三方聚合平台（如：磐河旅行），磐河旅行大约聚合了国内所有主流OTA平台和几十家酒店垂直B2B平台，对接他们一家相当于，对接了他们所有已整合的几十家渠道，且对接成本可能比任何单一渠道还要低。既经济（低门槛）又方便（已经给你聚合好了）

对接方式：
酒店对接方式主要分落库模式和实时搜索模式

落库模式： 就是把酒店所有静态信息（如 酒店基本信息、物理房型基本信息等）从对接的渠道那边下载 落到本地库，用户在查询时，只需要查询本地库即可。优点：可自定义搜索逻辑，弹性更大 ； 缺点：需要定期维护，对服务器和带宽要求很高，需要增加很多额外的维护更新成本

实时搜索模式：就是所有接口都使用渠道方的（包括 酒店搜索接口，酒店详情接口，房型价格接口等），不需要自建酒店数据库。优点：对接起来简单、方便、对服务器要求不高 缺点：依赖渠道方接口，如果渠道接口不满足业务需求的话，就很难弄

标准API接口方法：
想在自己的平台（APP、小程序 、H5等）实现完整的 酒店查询、预订、退订闭环流程，就需要用到 以下酒店API接口方法（按照流程顺序排序）：

1) 酒店搜索接口：供前端用户查询 搜索酒店使用，用于前端酒店搜索列表页

2) 酒店详情接口：酒店详情页使用，主要提供酒店静态信息，如酒店名称、地址、电话、图片等信息

3) 酒店实时房型和价格接口：根据酒店ID和入离日期，实时动态查询可预订的房型、价格和库存，包括 早餐、取消政策等信息

4) 酒店价格库存验证接口：用于下单前对客户选择的酒店房型价格进行 校验，主要是看 是否有库存，价格是否有变动，验证不通过的话就需要引导用户 重新查询刷新

5)下单接口：下单页，提交订单

6)支付接口：支付接口，分销行业一般都是余额代扣接口，很多渠道方，该接口和下单接口合并 一起（即下单成功同步扣除订单金额）

7)订单详情接口：主要用于轮询订单状态，订单详细信息，比如 支付成功后 需要轮询订单详情看是否预订成功，，退订后，需要轮询订单详情看是否退订成功

8)退订接口：预订成功后，如果预订的房型产品是可取消且当前时间在免费取消时限内，可通过该接口提交退订申请，申请成功后，通过轮询订单详情同步退订结果

通过以上API接口 ，就可以实现一个完整的酒店查询预订平台了，欢迎留言评论交流，文章最后附上，磐河旅行酒店开放平台接口文档地址：酒店接口文档-磐河旅行开放平台