成为赞助商——支持中文 Agent 生态

了解赞助
库Agent场景库
← 返回用例列表

Resend Webhooks 邮件事件接入简报

按 HTTPS 事件推送、端点登记、签名校验与重放,整理投递/打开/退信/点击等邮件事件接入简报;不代持 signing secret、不代改生产端点。

场景说明

面向独立开发者与轻量运营自动化:把「发信结果回流业务库」写成可对账步骤,区别于邮箱收件 Push。

案例叙事

01他们做了什么

独立产品用 Resend 发事务邮后,业务侧仍靠人工看仪表盘才知道退信——希望投递、打开、退信、点击自动回写用户表或告警通道。

Resend Docs《Webhooks》导论说明:Webhooks 是实时 HTTPS 请求,用于告知应用发生了事件(如投递通知或订阅状态更新),从而获得投递、打开、退信、点击等可行动更新。可在 Dashboard 或 API 创建、更新、观察与重试。载荷为 JSON,含 from、to、状态等元数据。文档列举常见工作流:自动从名单剔除退信地址;按事件类型在消息/事件工具告警;把发送事件存进自有库做报表/留存;以及接收应用 inbound 邮件。功能上支持重放任一 webhook 事件(端点漏接或处理器升级后重处理)、校验请求真实性、本地开发时监听,以及可自托管的 Webhook Ingester。快速开始:先在应用内建可接受 POST 的路由,再在 Resend 定义 webhook(端点 URL + 处理的邮件事件)。本场景据此输出接入简报。禁止声称「生产 webhook 已接通」或回显 signing secret。

02实际效果

  • 源未披露量化「退信自动剔除节省工时」;公开文只描述事件类型动机、登记步骤与校验/重放能力。
  • 能把「未验签 / 漏事件可重放 / 与收件箱 Push 混淆」拆开。
  • 为运营自动化提供发信结果回流的上游设计。

03值得知道

  • 具体事件名与重试策略以 Event Types / Retries 文档为准,导论页不替代字段表。
  • 验签须用官方 SDK/文档推荐方式;本地调试勿把 secret 写入前端。
  • 上面写的是产品能力说明,不是你账号下的 webhook 列表。

04可复制提示词

Resend Webhooks 接入简报

你是 Resend Webhooks 助手。只给接入核对简报,不要编造已接通。

业务目标:{{business_goal}}
拟监听事件:{{event_types}}
端点栈摘要:{{endpoint_stack}}
是否已有 signing secret(是/否,勿给值):{{has_secret}}

输出 Markdown:
1. POST 端点最小职责
2. Dashboard/API 登记提问
3. 验签与重放检查点
4. 测试域验收步骤
禁止索要 signing secret 值;禁止代改生产 URL。

退信未回流排查提纲

仪表盘可见 bounce/delivery,业务库未更新,请写排查提纲。

现象:{{symptom}}
端点日志摘要:{{logs}}
已订事件:{{subscribed_events}}

输出:
1. 事件是否订错
2. 验签失败是否被丢弃
3. 是否需 Dashboard 重放
4. 下一步人工验证
不要伪造「事件已写入业务库」。

05一手来源

怎么做

  1. 粘贴业务目标(退信剔除/告警/自建报表)、拟监听事件、端点栈摘要与是否已有 signing secret(勿贴值)
  2. Agent 按官方 Webhooks 导论输出:建 POST 端点→Dashboard/API 登记→校验签名→重放/本地监听提问清单
  3. 人工在测试域验证;Agent 不代登记生产 URL、不代存 secret

实用提示

  • 推送是实时 HTTPS JSON,含 from/to/状态等元数据;常见用法含自动剔除退信、按事件告警、自建报表,以及接收 inbound
  • 与 gmail-api-push-watch-checklist 不同:本条是发信服务商事件出站 Webhook,不是 Gmail 邮箱 watch/Pub/Sub
#Resend#Webhooks#邮件事件#退信#独立开发者