> For the complete documentation index, see [llms.txt](https://resources.atriptech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://resources.atriptech.com/chan-pin-jie-shao/atlas-chan-pin-jie-shao/webhook-shi-jian-tong-zhi.md).

# Webhook 事件通知

Webhook 用于把关键业务变化实时推送到你的系统。

它适合自动化运营、状态同步和异常响应。

### 典型事件

#### 出票结果通知

当订单出票成功或失败时，系统会推送结果。

常见内容包括订单号、票号、失败原因和处理建议。

适合触发：

* 订单状态更新
* 票号入库
* 失败补救流程
* 客服或运营告警

#### 废票进度通知

当废票请求状态变化时，系统会推送进度。

适合实时同步申请状态和下一步动作。

常见状态包括：

* 已提交
* 审核中
* 已提交航司
* 处理完成
* 已拒绝

#### 航班时刻变化通知

当航班发生时间调整、取消或机型变化时，系统会推送提醒。

适合触发改期评估、客户通知和人工介入。

#### 航司状态变化通知

当某个航司的连接状态发生变化时，系统会推送影响信息。

适合运营团队调整流量分配和预期管理。

#### 邮件捕获通知

当系统收到航司邮件时，可推送邮件分类、主题摘要和下载信息。

适合补充航变、票据和异常通知链路。

### 推荐接入顺序

{% stepper %}
{% step %}

### 先接出票结果

这是最核心的事件。

建议先打通出票成功、失败和取消后的状态同步。
{% endstep %}

{% step %}

### 再接售后与航变

接入废票进度、航变和邮件捕获。

这样可以覆盖履约后的关键变化。
{% endstep %}

{% step %}

### 最后接航司状态事件

这类事件更偏运营和风控。

适合在基础链路稳定后再接入。
{% endstep %}
{% endstepper %}

### 适合的场景

* 同步订单状态到下游系统
* 自动更新客服或运营面板
* 触发退款、改期或人工介入流程
* 追踪航司连接状态变化

### 使用建议

* 为每类事件设计幂等处理逻辑
* 记录推送日志，方便排查失败和重试
* 对字段新增和结构变化做兼容处理
* 将 Webhook 与订单主动查询结合使用

### 落地建议

#### 做好幂等处理

同一个事件可能被重复推送。

应基于事件类型、订单号和状态版本做去重。

#### 设置降级策略

如果推送消费失败，系统仍应能通过主动查询补齐状态。

#### 区分实时动作和人工动作

适合自动执行的事件应直接联动系统。

涉及退款、改期和争议判断的事件，建议进入人工审核流。

{% hint style="warning" %}
Webhook 以尽最大努力方式送达。

涉及航变时，请始终以航司发送到预订邮箱的邮件为准。
{% endhint %}