Notion Inbound Webhooks 实战：用外部事件直接触发工作流，告别轮询延迟

轮询触发的问题

n8n 的 Notion Trigger Beta 目前提供两个触发器：「Page Added to Database」和「Page Updated in Database」。1 两者都是轮询模式——n8n 每隔固定时间去查一次 Notion，问一句「有没有新变化？」

这带来一个实际问题：当你希望「GitHub PR merge 之后，对应的 Notion Task 立刻关闭」，轮询会在中间插入一段不可控的等待时间。Notion API 每个集成限速均值 3 请求/秒，高频轮询容易触发 HTTP 429 超限2，还会白白消耗配额。

2026 年 5 月 13 日，Notion 发布 3.5 Developer Platform，其中 Inbound Webhooks（Beta） 直接解决了这个问题：外部应用主动向 Notion 发 HTTP POST，Notion 收到信号后立即执行工作流，不再依赖轮询。3

Inbound Webhooks 是什么

Inbound Webhooks 允许任意外部系统（GitHub、Stripe、Slack、你自己的服务）向 Notion 注册一个 Webhook 端点，然后在事件发生时向这个端点发送 POST 请求，触发 Notion 内部自动化。3

Notion 官方给出的典型场景：

PR merge → 关闭对应 Notion Task
用户订阅变更 → 更新 CRM 数据库中的记录

需要区分两个容易混淆的概念：

概念	方向	用途
Inbound Webhooks（本文主角）	外部 → Notion	外部事件触发 Notion 工作流
Connection Webhooks	Notion → 外部	监听 Notion 内页面/数据库变更、推给外部系统

Connection Webhooks 适合做「Notion 变了，去通知 n8n」；Inbound Webhooks 适合做「外部发生了事，来更新 Notion」。4 两条路方向相反，别选错方向。

配置步骤

前置条件：准备访问凭证

Inbound Webhooks 需要通过集成（Integration）或个人访问令牌（PAT）授权 Notion 工作流有权写入目标数据库。

方式一：Internal Integration token（推荐团队场景）

进入 https://www.notion.com/my-integrations，创建 Internal Integration，获得以 ntn_ 开头的 bot token
在目标数据库页面点右上角「···」→「Add connections」，把这个 Integration 加进去（不做这步，写入请求会 403）4

方式二：PAT（Personal Access Token）（个人工作区快速上手） 2026 年 5 月 12 日上线的 Developer Portal 支持创建 PAT，无需逐个配置「Add connections」，token 直接继承你账号的全部访问权限。5 注意 PAT 有效期 1 年，Plus 计划所有成员均可创建，Free 计划仅 Owner 可创建。

注册 Inbound Webhook 端点

打开 Settings → Connections（Notion 3.5 统一了所有连接类型的管理入口3）
切换到「Inbound Webhooks」标签，点击「New Webhook」
填入来源系统名称，Notion 会生成一个唯一的 HTTPS 端点 URL（形如 https://api.notion.com/v1/webhooks/...），复制备用
在同一配置页面，指定「接收到请求后执行哪个 Automations 工作流」——可以是已有的 Database Automation，也可以新建

在 n8n 中配置发送端

在 n8n 中，你希望的逻辑是：「GitHub PR merge → 调用 Notion Webhook 端点」。

在 n8n 创建一个新工作流，起始节点选 GitHub Trigger，事件选 pull_request，过滤 action = closed + merged = true
添加 HTTP Request 节点，方式选 POST，URL 填入第二步复制的 Notion Webhook 端点
Headers 中加入 Authorization: Bearer <你的 Integration token 或 PAT>
Body 中传入你希望 Notion 工作流接收的 payload，例如：

{
  "pr_title": "{{ $json.pull_request.title }}",
  "pr_number": "{{ $json.pull_request.number }}",
  "repo": "{{ $json.repository.full_name }}"
}

在 Notion 的 Automations 工作流中，引用 Webhook payload 里的字段（字段名由 Notion 界面配置时提示），匹配对应 Task 并将 Status 更新为「Done」

使用前要知道的限制

Beta 状态：Inbound Webhooks 当前是 Beta，Notion 官方未公布 GA 时间表，字段和行为可能变动。3 建议在正式流程接入前先在测试数据库跑 2 周。

API 字段映射：2026 年 3 月 11 日的 API 版本更新中，archived 字段被移除，改用 in_trash 布尔值。6 如果你的 Automation 工作流里有根据 archived 判断状态的逻辑，需要同步更新，否则 Webhook 触发后工作流会静默失败。

速率限制依然存在：Inbound Webhooks 触发的后续 API 写操作同样受 3 req/s 限制约束2——Webhook 解决的是触发延迟问题，不是写入速率问题。批量更新多条记录时仍需加 retry/backoff 逻辑。

Internal Integration 权限范围：bot token 只能访问显式「Add connections」分享给它的页面和数据库，自动化范围仅限已授权的数据库，跨 workspace 的 Relation 无法写入。4

落地验证路径

两步确认通路正常后再接入正式流程：

用 Webhook.site 先收一个 payload——Webhook.site 是一个免费的 HTTP 请求调试工具，可以生成临时 URL。在 n8n 的 HTTP Request 节点先把目标 URL 换成 Webhook.site 的临时地址，触发一次真实事件，确认 payload 字段结构符合预期后再换回 Notion 端点
在测试数据库跑一条记录——触发一次真实 PR merge，观察 Notion 数据库中对应 Task 的状态是否即时变更，确认通路正常后再接入生产数据库

封面图：图片来自 Notion: What's New