Webhook 是在指定事件发生时，向已配置端点发送的 HTTP 请求。接收系统不必反复询问服务是否有更新；事件发生后，发送方可以主动通知它。GitHub 的Webhook 文档介绍了这种按事件发送数据的方式，并将其与间歇性轮询 API 作比较。
Webhook 如何工作
接收应用提供端点网址，发送方则配置需要报告哪些事件。事件发生时，发送方会发送包含事件资料的请求。接收端验证请求来源，检查需要的字段，再执行获准的操作，例如记录更新，或将事件放入队列稍后处理。
企业应用示例
以下示例仅用于说明：配送服务报告包裹状态变化时，零售系统可以接收 Webhook 并更新订单进度。员工之后可以在订单系统中查看报告的状态。实际做法取决于服务商提供的事件资料和零售商的集成设计。
Webhook、API 和工作流自动化
Webhook 负责发送事件通知；API 定义软件请求数据或操作的接口。接收 Webhook 后，系统可以再调用 API 获取完整资料。工作流自动化则通过触发条件、规则和操作来协调任务，Webhook 可以作为其中一种触发方式。可阅读API 说明和工作流自动化说明。
运营方面的限制
请求成功发出，不代表接收端已经成功处理。端点可能暂时不可用，数据格式可能变化，发送方也可能重试，导致同一事件送达多次。接收端应安全处理重试，记录送达状态，验证请求，并避免信任未经验证的内容。依赖及时更新前，应先了解发送方如何处理重试和失败。
如需了解服务范围，可以查看 technine.io 的系统集成与自动化服务。
常见问题
Webhook 是 API 吗？
Webhook 使用 HTTP 端点，但两者描述的是不同概念：Webhook 将事件发送给接收端；API 则是软件请求数据或操作的接口。
Webhook 能保证更新已成功处理吗？
不能。请求可能无法送达端点，也可能在处理过程中失败。发送方和接收方都需要规划重试、错误记录和恢复方式。
同一个 Webhook 会送达多次吗？
有可能。发送方遇到超时或送达错误时可能重试。接收端应识别重复事件，避免重复执行同一项更新。
主要资料来源：GitHub Docs：About webhooks