WhatsApp API 限流拆解：三种被混为一谈的机制，需要不同的修法

没有比发送中途失败更毁活动的了。撞墙发 WhatsApp 消息，多半撞上被统称为"rate limit"的三种不同机制——它们需要不同的修复。

三套独立系统，一个令人困惑的名字

消息量限制（volume）：Meta 对"24 小时滚动窗口内能首次联系（现有会话之外）的唯一电话号码数"的上限。回复入站消息不计入——客户先发消息后，每段对话免费获得一个 24 小时服务窗口。

吞吐（throughput）：发送速度，每秒消息数。超过即报错 130429（"message throughput has been reached"）——这是退避信号，不是封禁。

会话型 API 限制：如果用会话型 API 而非官方平台，消息量分层不适用——受你套餐的固定速率与月度请求配额约束。

官方分层阶梯

WhatsApp Business Account 按使用质量与一致性自动升级，不能买：起始 250 联系人/24h → Tier 2: 2000 → Tier 3: 10,000 → Tier 4: 100,000 → Tier 5: 无限。日额度挡不住吞吐错误：Tier 4 账户有 10 万联系人日额度，一小时发 9 万条照样被节流——那是吞吐问题不是量问题，两者独立跟踪。

什么触发封禁 vs 节流

Meta 错误码直接告诉你问题：130429 吞吐达限（发太快，减速）；131056 接收方限流（对单个号码太快）；131048 消息质量节流（收件人近期屏蔽/举报触发）；80007 账户级限流（整个 Business Account 到容量）。底下是质量评分——由屏蔽率、垃圾举报、互动构成。屏蔽数飙升能快速从 Green 掉到 Red，访问量随之自动收缩。发太快被节流，发得糟被封锁——不同问题不同修法。

代码层节流

无论什么套餐，自己尊重每秒上限，别指望 API 帮你排队：

// 尊重每秒上限，与套餐无关
async function sendBatch(numbers, message, session, requestsPerSecond = 10) {
  const delayMs = Math.ceil(1000 / requestsPerSecond);
  for (const [i, chatId] of numbers.entries()) {
    await axios.post('https://whatsapp-messaging-bot.p.rapidapi.com/v1/sendText',
      { chatId, text: message, session },
      { headers: { 'x-rapidapi-key': process.env.RAPIDAPI_KEY,
                   'x-rapidapi-host': 'whatsapp-messaging-bot.p.rapidapi.com' } }
    );
    console.log(`Sent ${i + 1} / ${numbers.length}`);
    await new Promise((r) => setTimeout(r, delayMs));
  }
}

安全扩容

预热新号码（低而稳的量持续 1–2 周再上真实流量）；分清单（营销只发给已 opt-in 和近期活跃的联系人——这保护质量评分）；429 退避（指数退避，不是重试循环）；盯交付率和屏蔽/举报率作领先指标，别只看发送成功率；走 24 小时窗口回复——客户发起的对话完全绕过每日消息量限制，你能发的最安全的量就是回复。

场景模式：电商把订单确认排队发送（秒级送达且不破上限）；SaaS OTP 按平均注册率之上留余量应对可预测尖峰（周一早、宕机恢复后）；客服团队靠入站触发回复——基本绕开限流。

要点："限流"实际是两件事——每日量上限与独立的每秒吞吐；官方平台层级升级靠持续优质使用挣来，不能买；会话型 API 跳过阶梯用套餐级限制；质量评分（由收件人行为驱动）决定你的真实权限，比原始量更重要；24 小时窗口内的客服回复是最安全的发送。

来源：WhatsApp API Rate Limits Explained: How to Scale Without Getting Blocked - DEV Community