获取 Offer

用于报价获取、可选附加服务、下单和出票的独立实时验价流程。

当你需要独立报价查询流程时，使用这页。

以 OpenAPI 命名为准。

文档和集成都统一使用 getOffers.do。

主要 API

• getOffers.do

输入

• 准确的行程信息

• 请求要求的乘客组合

• 当前 API 参考要求的其他字段

关键输出

• 最新可预订票价

• 库存状态

• 后续下单使用的 OfferId

它和标准搜索有什么不同

标准搜索流程

当 Atlas 是你的主购物入口时，使用 search.do。

这种方式适合先让 Atlas 返回可售报价。

Get Offer 流程

当你已经知道目标行程时，使用 getOffers.do。

这种方式更适合直接验价、独立校验和外部购物路径。

实际区别

标准搜索流程通常会继续走 verify.do。

Get Offer 流程则围绕返回的 OfferId 继续下单。

适用场景

• 不走标准搜索的报价查询流程

• 下单前二次验价

• 出票前最低价校验

• 使用你自有航班数据源的流程

常见场景

使用自有航班数据源

如果航班选择发生在 Atlas 标准搜索之外，可使用 getOffers.do。

这样可以直接获取最新可订票价和 OfferId。

下单前做最终验价

在创建订单前，通过 getOffers.do 再检查最新可订价格。

这样能减少报价和下单之间的价格漂移。

出票前比较渠道

如果你需要在送入出票前做一次实时校验，可使用 getOffers.do。

这适合以最新可得价格为优先的流程。

推荐业务链路

最短链路

只需要取价和出票时，使用：

1. 调用 getOffers.do

2. 保存返回的 OfferId

3. 调用 order.do

4. 调用 pay.do

带附加服务的链路

如果需要先选行李或座位，使用：

1. 调用 getOffers.do

2. 确认票价和目标航班

3. 如有需要，调用 getLuggage.do 或 seatAvailability.do

4. 用 order.do 创建订单

5. 用 pay.do 完成支付

何时停止并重新校验

若以下任一项变化，应停止并刷新报价：

• 目标航班

• 乘客组合

• 预期票价

• 会影响预订决策的附加服务需求

典型流程

1

获取 Offer

用目标行程调用 getOffers.do。

保存返回的 OfferId。

2

可选附加服务

如有需要，调用 getLuggage.do 或 seatAvailability.do。

只有当报价已匹配目标航班和价格时，再做这一步。

3

创建订单

用返回的 OfferId 和必填预订数据调用 order.do。

4

支付并出票

调用 pay.do 完成出票。

何时查询附加服务

使用 getLuggage.do

当行李价格或行李选项会影响转化时再用。

先确认目标 Offer，再查行李。

使用 seatAvailability.do

当座位可选性或付费选座会影响预订决策时再用。

不同航司的支持和会话规则可能不同。

保持附加服务可选

除非业务必须，否则不要把附加服务查询塞进基础链路。

生产最短路径仍然是 getOffers.do → order.do → pay.do。

实现建议

最适合谁

这条流程适合已掌控购物逻辑的合作方。

也适合下单前需要 Atlas 侧最终验价的场景。

需要保留的数据

保留调用 getOffers.do 时使用的完整行程上下文。

下单完成前持续保留返回的 OfferId。

建议校验点

在 order.do 前确认：

• 航班与目标行程一致

• 票价符合预期售卖逻辑

• 乘客组合仍然正确

• 如有要求，附加服务选择已完成

运行注意事项

真正依据

请求字段和响应字段都以 OpenAPI schema 为准。

命名

实现材料、支持回复和对外说明都统一使用 getOffers.do。

错误处理

如果下单或支付因票价或库存变化失败，应从新的报价查询开始。

不要基于过期假设直接重试。

FAQ

getOffers.do 会替代 search.do 吗？

不会。

当 Atlas 是主购物入口时，用 search.do。

当你已知目标行程，或需要独立验价时，用 getOffers.do。

这个流程还需要 verify.do 吗？

按本页描述的标准 Get Offer 路径，不需要。

这个流程围绕 OfferId 和后续下单展开。

附加服务查询是必需的吗？

不是。

只有在下单前必须确认座位或行李时，才用 getLuggage.do 或 seatAvailability.do。

什么时候应刷新 Offer？

当任何关键预订输入发生变化时，都应刷新。

常见触发条件：

• 乘客人数变化

• 目标航班变化

• 预期票价变化

• 下单前等待过久，当前价格可能已过期

可以配合自有购物引擎使用吗？

可以。

这是这条流程的主要使用场景之一。

请确保你的行程映射与 OpenAPI 中定义的请求字段一致。

失败处理

如果 getOffers.do 失败

先检查请求是否完整。

再确认行程、乘客和 OpenAPI 要求的必填字段。

若为瞬时问题，可做受控退避重试。

如果 Get Offer 之后 order.do 失败

不要假设原先返回的 Offer 仍然有效。

如果失败指向票价、库存或状态漂移，请重新调用 getOffers.do，再基于新数据重建订单请求。

如果 pay.do 失败

先检查订单是否已支付，或是否仍在处理中。

不要盲目重复支付。

必要时先查询订单状态再决定是否重试。

什么情况下不要立刻重试

以下原因导致的问题，不应立即重试：

• 过期票价数据

• 不支持的支付方式

• 无效乘客或联系人数据

• 航司侧限制

先修复根因。

日志和支持建议

日志中至少保留这些值

排障时建议记录：

• 请求时间戳

• 行程摘要

• 乘客组合

• OfferId

• 下单后的 orderNo

• 支付方式类型

• 最终响应状态和消息

保持请求链路可追踪

把 Get Offer 请求和后续订单请求记录为同一条业务链路。

这样更容易定位价格漂移和状态不一致。

升级支持时提供什么

升级问题时，请提供：

• API 名称

• 请求时间

• OfferId 或 orderNo 等关键标识符

• 响应码

• 响应消息

这会显著加快支持排查。

说明

• 这条流程不从标准 search.do 开始。

• 必填字段以当前 API 参考为准。

• 接口命名以 OpenAPI 为准。

• 实现材料中统一使用 getOffers.do 作为正式接口名。

相关页面

• 搜索

• 创建订单

• 支付与出票

• 座位与行李

完整 API 参考

接口级详情见：

• 获取 Offer

• 预订中座位与行李

• 创建订单

• 支付与出票