Knock.app 替代方案（2026）：事务 HTTP 邮件 API 与域名邮箱

对照 Knock 的通知基础设施（workflows、应用内 feeds、guides、BYO 服务商）与 Rovela 的扁平 POST /emails、Idempotency-Key、入站与域名邮箱——何时双跑。

为什么有人会搜 Knock.app 替代方案

Knock 是通知 / 产品消息基础设施：用 workflows 编排事务与生命周期消息，覆盖邮件、短信、推送、聊天与应用内 feeds，并提供 guides（站内横幅/弹窗）、偏好、多租户，以及自带投递服务商（BYO providers）。其文档描述了带 function steps（batch、delay、branch）的 workflows、带实时 socket 的 feed API，以及自接 SendGrid / Postmark / SES / Twilio / FCM / APNs 等账号（Knock’s features、Workflows、Feeds）。

2026 年搜 “Knock alternative / Knock.app 替代” 的开发者意图，通常是下面几类——不是说 Knock 做不好跨渠道通知基础设施：

想要扁平的 HTTP 邮件发送（POST /emails，带 from / to / subject / html 或 text），任意语言、队列工人或 AI agent 都能直接调用——而不必先把每封 OTP 或收据都建模成 Knock 的 workflow key + 收件人档案 + channel steps。
产品对事务流量基本是只做邮件（或以邮件为主），再在独立 ESP 之上叠一层通知编排，成本和部件暂时用不上。
更习惯按发送量 + 域名 + 邮箱计价，而不是按通知消息 / 被通知用户计价——尤其当量主要是鉴权码、密码重置、收据，且应用已经自管这些状态。
需要同一组织下、人能打开的企业邮箱（hello@、support@，Webmail/IMAP），而不只是出站渠道进用户产品 feed 与收件箱。
需要入站回复与带签名的投递 Webhook，挂在精简发送 API 旁边。
双跑：Knock 继续做应用内 feeds、guides、短信/推送/聊天与带偏好的 workflows；高频仅邮件的事务流量走更薄的 HTTP 邮件栈（或其他渠道仍走 Knock，邮件热路径直连邮件 API）。

Rovela 不会复制 Knock 的 workflow 引擎、应用内 feeds、guides、偏好中心、多渠道路由或 BYO 服务商抽象。它对准的是该搜索里开发者事务邮件 + 域名邮箱这一侧。本文只写文档可核对的内容：何时仍该用 Knock、Rovela 实际交付什么、以及如何迁移线上邮件 POST 路径——不编造应用内/推送对等能力。

其他关键词类别的兄弟文（勿混钩子）：Courier.app 替代（多渠道编排 / Design Studio——相关但是另一品牌）、Customer.io 替代、Loops.so 替代、Resend 替代（邮箱 + 入站）、SendGrid 替代（简单 HTTP）、Postmark 替代、Mailgun 替代、Brevo 替代、Mailtrap 替代、Amazon SES 替代、SparkPost 替代。本文主关键词仍是 Knock / Knock.app。

何时 Knock 仍是正确工具

继续用——或双跑——如果：

需要一套通知 API，用 workflows 覆盖邮件、短信、推送、聊天与应用内，并在每次运行时强制偏好（Knock 在 knock.app 与 docs features 上的定位）。
应用内 feeds、toasts、未读角标或实时 feed socket 是硬性产品需求（Feeds overview）。
Guides（横幅、弹窗、付费墙、公告）需要非工程师也能参与运营，而不仅是一段 curl（Knock’s features）。
已经接了多家服务商，希望用 channel steps、batch/digest、delay、branch，而不改应用代码（Workflows）。
明确想要编排层叠在你已付费的 ESP / 短信 / 推送之上——Knock 按消息 / guide recipients 计费，服务商账号仍要自管（Knock pricing FAQ）。

如果你真正需要的是 Knock 的通知基础设施层，Rovela 不是合适的「整包替换」。更适合选 Rovela 的场景是邮件基础设施痛点：已验证域名的 POST /emails、Idempotency-Key、入站与域名邮箱——并带有可长期停留的 Free 档，方便边车项目与 agents（Pricing）。

通知基础设施给应用自管邮件留出的空间

Workflows + feeds + BYO ESP vs 扁平邮件正文

Knock 的强项是通知基础设施：触发 workflow（API、事件源或调度），评估偏好，跑 channel 与 function steps，再通过你接好的服务商投递。邮件只是众多渠道之一；生产邮件通常仍依赖 Knock 下的某个 ESP 账号（Knock’s features）。应用内 feeds 与 guides 是一等产品面，不是附带功能（Feeds）。

应用自管的 OTP、密码重置链接与 agent 工具，对邮件往往要相反形态：在你的数据库生成密钥，再向邮件 API 打一发扁平 JSON——不必把收件人同步进通知平台，不必 workflow key，不必 channel 列表，也不必在工人与邮箱之间再隔一层厂商。Rovela 的发送路径就是一次调用——POST https://api.rovela.dev/emails——Bearer 鉴权（Quick Start、API: emails、HTTP email API）。若你确实想要 template: { id, variables }，Rovela 也有可选 templates，但发信并不强制。

Rovela 不宣称短信、移动推送、Slack/Teams 投递、应用内通知 feed 或 guides。若这些表面是硬需求，请继续用 Knock（或其他通知平台）承载。

通知消息计价 vs 发送量 + 邮箱上限

Knock 围绕 messages sent（向某用户在某渠道投递的一条消息）打包，另加 guide recipients 与 agent credits——详见 Knock pricing 上的 Free / Starter / Enterprise（数字只从该页引用）。Rovela 按每月邮件数、域名、邮箱与存储计价——Free 为 100 封/月、1 个域名、5 个邮箱、1 GiB，无需绑卡；Pro 从 $29/月 起提高上限（Pricing）。架构前请重读两边定价页。记住：Knock + ESP 对邮件渠道往往意味着两份账单；Rovela 本身就是邮件投递产品。

Workflow / feed UI vs agent 能持有的密钥

通知平台优化 workflow 构建器、feed SDK、guides 与偏好中心。只需要发邮件的 agent / worker 栈，往往更想要只能发送、不能改域名或模板的 sending_access 密钥（Authentication）。切勿把 sending_access（或任何 API key）打进浏览器包——从你的服务端调用 Rovela。

发送旁边的人类邮箱与入站

Knock 聚焦通过已接服务商与应用内渠道做产品消息。若团队还需要可在 Webmail/IMAP 打开的 support@yourdomain.com，以及解析到 Webhook 的入站，Rovela 在同一组织内提供（webmail、SMTP、Receiving email）。Free 含 5 个邮箱；付费计划提高数量与存储（Pricing）。

工人重试时的幂等

Rovela 接受 Idempotency-Key 请求头（最长 256 字符）；24 小时内的重试返回原响应而不再发一封（API: emails）。这对队列驱动的 OTP 与收据很重要——两次 POST 导致两个不一致验证码，就是客服事故。

文档可核对地图：发送、鉴权、邮箱、入站

1. 一次发送：`POST /emails`

curl -X POST https://api.rovela.dev/emails \
  -H "Authorization: Bearer re_your_sending_key" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: knock-migrate-receipt-order_10422" \
  -d '{
    "from": "Acme <no-reply@yourdomain.com>",
    "to": "alice@example.com",
    "subject": "Your Acme receipt",
    "html": "<p>Thanks. Order <b>A-10422</b> is confirmed.</p>",
    "text": "Thanks. Order A-10422 is confirmed."
  }'

响应：入队消息 id（{"object":"email","id":"..."}）。200 表示已接受投递，不是「已进收件箱」。
可选模板路径：用 template: { id, variables } 代替 html/text（Templates guide、Templates API）。模板管理需要 full_access（或控制台）；生产发送端应使用 sending_access。
批量：POST /emails/batch 最多 100 条；batch 上拒绝 template——带模板的邮件请逐封发（API: emails）。

2. 域名验证

添加域名，发布 SPF/DKIM/DMARC（以及所示 return-path），再验证（Quick Start、Domains）。未验证的 from 域名会得到 400，而不是静默丢弃。

3. 投递 Webhook

订阅 delivered/bounced/complained（及相关）事件；校验签名；按事件 id 去重（Webhooks、Security）。优先 Webhook 而非轮询。读取消息状态需要 full_access 或控制台会话；sending_access 只能发送。

4. 企业邮箱

Webmail 在 rovela.email；SMTP 主机 mx.rovela.dev，端口 465，用户名为完整地址，按设备密码（SMTP、webmail manual）。

5. 入站

在已验证域名上启用入站（full_access），发布 MX，订阅 email.received（Receiving email）。模式见：Inbound email API webhooks。

迁移清单（Knock 口味）

保留 Knock 承载 workflows、应用内 feeds、guides、短信/推送/聊天与带偏好的多渠道产品消息——不要把 feeds 或推送硬塞进只做邮件的 API。
创建 Rovela 组织，先用 Free 验证线上邮件投递（signup）——长期免费档，无需绑卡（Pricing）。
验证生产发信域名（按提示配置 DKIM / SPF / DMARC / return-path）。
创建 sending_access 密钥给应用服务器与 agents；域名、模板、入站管理继续用 full_access（Authentication）。
按意图拆流量：workflow / feed / 多渠道通知 → Knock；仅邮件的 OTP / 重置 / 收据工人 → POST https://api.rovela.dev/emails。
每封可重试的事务邮件加 Idempotency-Key（otp-{userId}-{purpose}、reset-{tokenHashPrefix}、receipt-{orderId}）。
把退信/投诉 Webhook 指到你的处理器；切邮件流量前先验签。
**可选：**出站稳定后再建邮箱并启用入站。
**可选：**用 full_access 把重复 HTML 做成 Rovela 模板，再按 id 发送——与 Knock workflow 里邮件 channel 模板思路相近，产品不同（welcome from template）。
不要假设 Rovela 是现成的 Knock 邮件 channel 服务商——除非你对照 Knock 当前集成列表与 Rovela 的 SMTP/API 文档自行验证；本文不编造官方 Knock↔Rovela 连接器。

搜这个关键词的大多数团队会继续用 Knock 做通知基础设施，只把（或只从）仅邮件热路径迁到事务邮件 API。这种拆分很正常——不是任一产品的失败。

不编造数字的定价对照

需求	Rovela Free（文档）	说明
每月发送	100 封邮件	见 Pricing
邮箱	5	同一免费计划
存储	1 GiB	同一免费计划
银行卡	不需要	长期免费档
API / Webhook / 入站 / 模板	包含	升级提高上限

付费 Rovela 计划（定价页上的 Pro、定制 Enterprise）提高邮件、域名、邮箱与存储上限。Knock 的打包（Free 消息/guide 窗口、Starter 平台费 + 超量、Enterprise 定制）应只从 knock.app/pricing 引用——比较时不要在本文编造超出你已核对页面的数字。若邮件以外渠道仍走 Knock，还要为底层 ESP / 短信 / 推送服务商预留预算。

Rovela 定价表也列出 broadcasts、contacts、segments 等随计划限额的 API 能力；那与 Knock 的 workflows、feeds、guides 或带偏好的多渠道路由不是同一产品面。不要把 Rovela 营销成 Knock 克隆。

本文不是什么

不是说 Knock「邮件做得差」——其模型本就是叠在服务商之上的通知基础设施，feeds 与 guides 是一等表面。
不是说 Rovela 能替换 Knock 的 workflows、应用内 feeds、guides、短信、推送、聊天、偏好、多租户品牌或 BYO channel steps。除非 Rovela 文档写明，这些都超出范围——而多渠道通知基础设施也不是 Rovela 的定位。
不是 Courier / Customer.io / Loops / Resend / SendGrid / Postmark / Mailgun / Brevo / SES / Mailtrap / SparkPost 的换皮；那些见上文兄弟文。Courier 是相关的「编排替代」关键词——本文专指 Knock.app。
不编造 MCP 工具、中国境内 ESP 话题或未文档化的端点。截至撰写时没有可照抄的 /alternatives/knock 营销页。
不是 Rovela 自带的密码重置或 OTP 产品功能：令牌/验证码仍由你的应用拥有；Rovela 负责投递（password reset example、verification codes）。

下一步

若 workflows、feeds 与 guides 仍合适，继续把多渠道通知基础设施放在 Knock。
用 Quick Start + POST /emails 发一封真实事务邮件。
若人需要收件箱，加邮箱并打开 webmail。
若回复或 support@ 重要，启用 inbound。
鉴权邮件模式见：验证码 vs 链接、安全密码重置、OTP / 魔法链接进垃圾箱。

一句话：搜 Knock.app 替代，往往仍想用 Knock 做 workflows、应用内 feeds 与跨渠道产品消息——但应用自管的邮件需要扁平幂等的 POST /emails、按发送量计价的 Free/Pro，以及团队能打开的邮箱。Rovela 做的就是这块邮件基础设施。渠道与 feeds 增殖的地方留下通知平台；仅邮件热路径按上文文档迁移。