Webhook 是一种自动通知，当特定事件发生时，一个系统会立即向另一个系统发送通知。它以 HTTP 请求的形式发送到预先配置的 URL，而不需要接收方系统反复询问是否有变化。在 Feed 管理中，正是 Webhook 让 ERP 中的价格变更、店铺中的新订单或仓储系统中的库存更新能够立即通知 Feed 平台，而无需该平台按定时器轮询变化。它们将 Feed 更新从计划批处理任务转变为事件驱动的任务。
为什么它对 Feed 管理很重要
轮询（反复检查源系统是否有变化）会浪费资源并带来延迟：如果 Feed 工具每十五分钟检查一次库存，那么一件已售罄的商品可能会在购物渠道上继续展示长达十五分钟才被发现。Webhook 通过让源系统立即推送变更来消除这种延迟，因此在下午 2:00:03 被标记为缺货的商品，可以在下午 2:00:04 之前从在售商品信息中撤下。这种即时性对任何时间敏感的场景都最为重要：限时抢购、限量库存发售，或与竞争对手进行价格匹配，在这些场景中，即使是很短的延迟，也可能意味着售出已经无货的商品，或者展示已经不准确的价格。由于 Webhook 依赖与其他任何 API 调用相同的底层请求-响应机制，它们可以直接融入现有的 Feed 自动化流程，无需单独的集成模式。
如何运作
设置 Webhook 意味着在源系统（仓储管理工具、CMS、支付处理商）中注册一个回调 URL，并告诉它哪些事件应触发通知。当该事件发生时，源系统会向注册的 URL 发送一个 HTTP POST 请求，事件详情位于请求正文中，而事件类型或用于验证的签名等元数据则通过 HTTP 标头传递。接收方系统（通常是 Feed 平台）随后处理该载荷并更新相关商品数据。由于 Webhook 是实时触发的，而且经常集中爆发（设想一次批量价格更新同时触发数百个单独事件），大多数系统会将传入的 Webhook 调用放入队列并异步处理，而不是立即同步处理每一个调用，从而避免接收端不堪重负。Webhook 是更广泛的工作流自动化的核心构建模块，因为正是它们让一个无关系统中的操作能够触发一连串下游 Feed 更新，而无需任何人手动监控变化。
示例
<item>
<g:id>SKU-55810</g:id>
<title>Wireless Charging Pad - Matte Black</title>
<g:availability>out of stock</g:availability>
<custom_label_1>updated_via_webhook</custom_label_1>
<last_event>inventory.zero</last_event>
<last_updated>2026-08-15T14:00:04Z</last_updated>
</item>在这里，last_event 反映了触发该商品库存状态变化的库存系统 Webhook 载荷，而几乎即时的 last_updated 时间戳，正是采用事件驱动更新而非计划批量刷新所带来的实际效果。
相关概念
Webhook 依赖与任何 API 调用相同的请求结构，只是方向相反，由源系统而不是 Feed 平台发起；该请求上的 HTTP 标头携带了正确信任和路由请求所需的身份验证和事件元数据。将多个系统中的 Webhook 串联起来，它们就成为 Feed 管理中大多数工作流自动化背后的触发层，这也是为什么一次库存变化就能连锁引发商品信息更新、广告暂停和 Feed 条目刷新，而无需任何人手动操作。
