MailerLite Comfort API 与 Webhook：需要升级 Power 吗？

1. 为缺少的权益付费，不为 API 名称付费

当前价格 FAQ 显示 Comfort 每月 12 美元起，Power 每月 25 美元起；两种付费套餐卡均列出完整 API 权限。Free 的 API 权限受限，不能通过 API／MCP 路径发送。Power 提供更高的发送、团队与启用功能容量；不限发送仍受合理使用规则约束。

起步价相差 13 美元，不代表你的账户也只差这个数。应按同一订阅人数档位、计费周期、税费与币种比较实际结账价。队列处理失败，不能证明 Power 提供更高 API 吞吐量。

部分活动接口文档还保留 Growing Business／Advanced 旧名称。官方迁移 FAQ 已明确对应 Comfort／Power，并说明账户在续费或手动改变方案时迁移。因此应核对实际账户的套餐结构，不把旧名称误读为新的权限限制。

2. 三种请求预算分别核算

当前 API 入门文档规定每分钟 120 次请求，超限会返回 429。应遵守返回的重试提示并平滑突发请求，而不是立刻反复重试。Token 绑定创建它的用户；该用户被移除后，Token 无法继续认证。

批处理每次最多包含 50 个调用，API batch 不支持 Webhook 操作。若整批都是订阅者 upsert，就走导入路径，额外受每分钟 5 次导入创建请求限制；这不是每分钟只能导入 5 个联系人。还要检查每个子请求结果，不能把外层响应成功当作整批全部成功。

记录最繁忙的短时窗口，而不只看全天平均。整点集中释放任务，可能超过限制；相同任务分散处理却可能完全够用。为重试和工作人员操作保留余量。如果分批与节流已经解决问题，就不能把解决效果算成升级价值。

3. 先确认接收，再做耗时业务处理

MailerLite 文档说明只向有效账户交付 Webhook，接收器应在不到三秒内返回成功的 2xx；失败后还会按 10、100、1000 秒延迟再尝试三次。当前 API 使用 Signature 请求头，对 JSON 内容采用该 Webhook 密钥的 HMAC-SHA256 签名。这些是当前 API 规则，不能套用到 Classic。

本文建议先验证原始请求内容，持久保存事件，及时确认，再由工作进程执行较慢的 CRM 操作。不能在事件尚未可靠保存时就确认成功。若持久化失败，应告警并保留恢复方式，而不是静默丢弃消息。

重复处理必须没有额外副作用，重试不能生成重复联系人或扣款。按当前结构测试单事件与批量内容；事件表要求活动打开、点击与订阅者删除支持 batchable。这是建议架构，不是本站实测交付保证。

4. 还要测试根本不会到达的事件

产品帮助页有一个关键例外：人工重新激活不会触发 subscriber.active。开发者文档中的概括描述必须结合这一例外理解。只依靠该事件同步，可能漏掉工作人员的手动修改。

用无敏感信息的测试联系人记录哪些操作产生事件，哪些操作需要对账。不能把 active 状态或收到回调当作新的营销同意。应单独保留同意证据，也不能让对账程序自动重新订阅已经退出的联系人。

员工离职前同样需要处理 Token 所有权：先列出依赖任务，验证替代凭据，再移除创建者。保护密钥，避免在日志中保留不必要的个人资料。这些运维检查不是套餐宣传可以证明的结果。

5. 跨平台比较实际运行规则

Mailchimp 文档介绍受众事件处理与签名验证；Brevo 按接口列出请求上限，并另外公布重试规则；ActiveCampaign 说明每个账户每秒五次请求及 Retry-After 处理。应拿同一负载比较不同计量单位和交付规则，而不是据此排列进箱率，或推断 MailerLite 具有同样能力。

逐个平台核对哪些请求计入限制、服务中断后如何处理、怎样验真，以及所需能力属于哪个方案。更高的宣传上限，也无法弥补平台根本不发送的关键事件。

6. 做一次小型故障测试后再决定

付款承诺前建议完成四项检查：目标账户下所需读写正常；重复事件和下游故障不会丢任务或重复执行；突发任务在官方预算内排空；人工重新激活与 Token 创建者移除都有明确恢复办法。分别记录预期和实际结果，未测试前不要预填通过。

检查通过且营销容量足够，就保持 Comfort。只有已核实的席位、发送、自动化或其他方案额度阻塞真实工作流时，才考虑 Power，并比较账户里的实际差价。把工程成本与订阅成本分开，不把假设的节省写成固定回报。

结论是为文档证实的缺失能力付费，不是相信更贵套餐会修好集成。通过 MailerLite 购买按钮下单，Toolnavia 可能获得佣金；链接不会提供专属折扣、提高请求上限或保证交付。