在线演示

指南

什么是 API 集成，为旅游企业讲清楚

API 集成是一种连接，让两个软件系统无需人工重复录入即可交换数据并触发操作。本指南以一笔酒店预订为例，讲解它如何在旅客、预订平台、供应商 API 和支付网关之间流转。

  • 一个请求，一个响应
  • REST、XML、SOAP 与 webhook
  • 一笔预订贯穿四个系统
  • 集成如何测试

定义

什么是 API 集成，用通俗的话说

API 即应用程序编程接口：系统对外公布的一套规则，让其他软件可以与之对话。API 集成就是把你的平台接入其中一个接口，使数据自动流动、操作自动发生。

在旅游行业，这个平台通常是像 旅游预订软件 这样的预订系统，而接口属于供应商、支付网关或业务工具。我们的 旅游API集成 页面介绍 PHPTRAVELS 如何交付这些连接，全部集成 列出了已接入的供应商。

  • 交换数据

    价格、库存、客户信息和状态更新以结构化格式在系统之间流动。

  • 自动执行操作

    搜索、预订、支付、取消和对账以请求的形式完成，而不是由人反复手工操作。

  • 追踪结果

    每次调用都带有引用号，失败的预订可以追溯到引发它的那个请求。

请求

POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{  "city": "DXB",  "check_in": "2026-11-12",  "check_out": "2026-11-14",  "guests": 2,  "currency": "USD"}

响应

HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{  "hotel": "Palm Marina Hotel",  "room": "Deluxe, 2 adults",  "rate": { "amount": 438.00, "currency": "USD" },  "refundable": true,  "rate_key": "rk_19d2c7"}
向一家虚构酒店供应商发出的示例调用。字段名、端点和金额因供应商而异。

一次 API 调用的构成

  1. 1

    端点与方法

    操作的地址以及作用于它的动词：对 availability 发出 POST 即表示搜索客房。

  2. 2

    身份验证

    密钥、令牌或签名证明调用者身份。供应商会为沙箱和生产环境分别签发凭据。

  3. 3

    载荷

    结构化输入：城市、日期、人数和货币。每个字段都由供应商文档定义。

  4. 4

    状态码

    表示调用结果的数字：200 为成功，4xx 为请求有问题，5xx 为供应商一侧出错。

  5. 5

    请求 ID

    双方共同保存的标识符。当客服询问某笔预订发生了什么，查的就是它。

  6. 6

    响应正文

    以供应商格式返回的答复，由你的平台映射为自己的客房、价格和政策。

一笔预订，四个系统

API 集成在一次酒店预订中做了什么

跟随一次两晚住宿，从搜索到出具凭证。每个箭头都是一次 API 调用；旅客只看到第一个和最后一个。

  1. 01旅客预订平台搜索迪拜酒店，两晚，两位客人
  2. 02预订平台供应商 API携带日期、人数和货币的库存请求
  3. 03供应商 API预订平台客房、价格、政策和价格键
  4. 04预订平台旅客套用你的加价和货币后展示结果
  5. 05预订平台供应商 API付款前对所选价格键重新核价
  6. 06预订平台支付网关对总额发起支付授权
  7. 07支付网关预订平台已授权，收到签名 webhook
  8. 08预订平台供应商 API携带客人信息的预订请求
  9. 09供应商 API预订平台确认号和取消条款
  10. 10预订平台旅客凭证、发票和预订参考号

中间的平台就是 API 集成所在的位置：它在旅客的屏幕和每家供应商的格式之间转换，并保存每一个引用号。

同样的流程适用于接入 GDS 的 机票预订软件、接入活动供应商的 旅游运营商软件，以及接入任意网关的 支付网关集成；变化的只是字段名。

集成方式

REST、XML、SOAP、webhook 与 GraphQL

供应商以不同方式发布接口。采用哪种方式由供应商文档决定，而非个人偏好，所以旅游平台需要全部掌握。

  • REST 与 JSON

    JSON
    数据格式
    JSON 文档
    传输方式
    HTTP 方法：GET、POST、PUT、DELETE
    旅游行业常见于
    较新的机票、酒店、活动和支付 API
    优势
    载荷紧凑，开发工具丰富
    注意事项
    规范松散；各供应商对 REST 的理解不同

  • XML 与 SOAP

    XML
    数据格式
    XML 文档，常带严格的模式
    传输方式
    带 SOAP 信封或纯 XML 的 HTTP POST
    旅游行业常见于
    GDS、床位批发商以及成熟的酒店和旅游系统
    优势
    正式契约、签名和服务定义
    注意事项
    报文冗长，解析更重

  • Webhook

    EVENT
    数据格式
    由对方推送的 JSON 或 XML
    传输方式
    向你注册的 URL 发出 HTTP POST
    旅游行业常见于
    支付结果、预订状态变更、出票更新
    优势
    无需轮询；有事件发生时平台会被通知
    注意事项
    必须验证签名并处理重复推送

  • GraphQL

    QUERY
    数据格式
    JSON，形状由你发送的查询决定
    传输方式
    单一 HTTP 端点
    旅游行业常见于
    部分较新的分销平台和内部 API
    优势
    只请求你需要的字段
    注意事项
    旅游供应商的支持仍不普遍

API 集成与 API 开发的区别

API 集成

把你的产品接入一个已经存在的接口。API 归供应商所有；你负责构建客户端、映射以及围绕它的规则。

API 开发

创建一个供其他系统接入你产品的接口，例如代理商工具可以调用的 B2B API。契约及其版本由你掌控。

许多旅游项目两者都需要：平台一侧集成供应商，另一侧向代理商和合作伙伴发布自己的 API。

集成前后

系统集成后会有什么变化

同样的五个预订步骤，一种是在供应商门户里手工完成，一种是通过 API 集成完成。

搜索

未集成手工

代理人逐个打开供应商门户，把价格抄进报价单。

API 集成后自动

一次搜索同时发往所有已接入的供应商，返回一份列表。

定价

未集成手工

加价在电子表格里添加；报价发出时价格可能已经变了。

API 集成后自动

加价、税费和货币规则在响应时套用；付款前重新核价。

预订

未集成手工

客人信息被重新录入供应商门户；错字变成预订错误。

API 集成后自动

信息只发送一次，经过校验，并与供应商确认一起保存。

支付

未集成手工

款项另行收取，稍后再与预订匹配。

API 集成后自动

授权、扣款和退款都绑定到预订参考号。

售后

未集成手工

取消和变更意味着再登录一次、再发一封邮件。

API 集成后自动

变更和取消走同一条连接，并更新记录。

API 集成出现在旅游平台的哪些地方

术语

API 文档中会遇到的术语

几乎每个供应商开发者门户都会出现的十二个词，按旅游行业的用法解释。

  • API

    应用程序编程接口：与某个系统对话的公开规则。

  • 身份验证

    证明调用者是谁，通过 API 密钥、bearer 令牌、签名或经批准的 IP 地址。

  • 认证

    供应商在签发生产凭据之前对你的集成进行的审核。

  • 端点

    一个操作对应一个地址，例如搜索、预订或取消。

  • 幂等性

    同一请求发送两次只产生一个结果，从而避免重复预订和重复扣款。

  • 映射

    把供应商的字段、代码和名称转换为你平台自己的数据模型。

  • 载荷

    请求或响应中携带的数据，通常是 JSON 或 XML。

  • 速率限制

    供应商每秒或每天允许的调用次数，超过后开始拒绝。

  • 请求与响应

    一次调用：你的平台提问，供应商回答，双方都记录日志。

  • 沙箱

    带有虚拟库存和测试卡的测试环境，不会真正预订或扣款。

  • 状态码

    概括结果的 HTTP 数字：200 成功、401 未授权、429 超出速率限制、500 供应商错误。

  • Webhook

    反方向的调用：事件发生时，供应商或网关通知你的平台。

测试与范围

旅游 API 集成上线前如何测试

只有异常路径也表现正常，集成才算完成。在供应商沙箱中运行一轮测试，覆盖下列用例，然后再进行认证并切换到生产凭据。

run integration tests

供应商沙箱，九个用例

  • OK: 使用有效和过期凭据进行身份验证
  • OK: 无效请求被拒绝并返回可读的错误
  • OK: 供应商超时得到处理，不会留下悬而未决的预订
  • OK: 遵守速率限制，等待后重试
  • OK: 重新核价时发现价格变动并在付款前展示
  • OK: 重复提交返回第一笔预订，而不是新建第二笔
  • OK: 取消已执行并计算费用
  • OK: 退款对原支付发起
  • OK: 预订、支付和供应商参考号相互对账

全部用例通过，可以提交认证

确定范围时需要你提供

  1. 1供应商协议、文档和沙箱凭据
  2. 2市场、货币、产品和用户角色
  3. 3搜索、预订、变更、取消和退款的范围
  4. 4认证要求和生产环境开通流程

准备好接入供应商了

PHPTRAVELS 把供应商、网关和业务工具集成到一个自托管平台中，并随源代码交付。查看 价格 了解三个一次性付费方案，或就某个具体 API 向我们咨询。

申请演示联系我们

继续阅读

常见问题

关于 API 集成的常见问题

首次集成项目前大家常问的问题，这里给出简短回答。

联系销售

API 集成是一种连接，让两个软件系统自动交换数据并触发操作。一方发送结构化请求，另一方返回结构化响应，双方都遵守约定的安全和数据规则。

在旅游行业，它把预订平台与机票、酒店、旅游或租车供应商、支付网关和业务工具连接起来，支持搜索、核价、预订、取消、退款和对账，无需重复录入。

REST 是一种架构风格，通常通过 HTTP 交换 JSON。XML 是一种数据格式，在 GDS 和床位批发商中仍很常见，常包裹在 SOAP 里。用哪一种由供应商的合同和文档决定。

取决于供应商的开通、范围内的端点、认证、映射规则和预订的边界情况。只有在审阅文档、凭据和所需流程之后，才能给出可靠的估算。

测试身份验证、有效和无效请求、超时、速率限制、价格变动、重复提交、取消、退款和对账。在生产环境中，每个请求都应能追溯到一个预订参考号。

不是。集成是把你的产品接入现有 API；开发是创建一个供他人接入的接口。旅游平台往往两者都需要：一侧集成供应商，另一侧向合作伙伴发布 B2B API。

继续探索

了解平台的更多内容