WhatsApp API rate limits diagram — three limit systems: per-second throughput, daily messaging tier, per-recipient frequency cap — with quality rating feedback loop
In this article: The three rate limit systems · Messaging tier table · Tier progression rules · Quality rating (GREEN/YELLOW/RED) · Per-recipient frequency cap · Exact error codes and responses · What never to retry · Account pausing behavior · Production retry code · Number warm-up strategy · FAQ

The three rate limit systems — and why they're different

The most important thing to understand about WhatsApp rate limits: there are three completely separate systems, each maintained independently by Meta's infrastructure. Hitting one does not mean you've hit the others. Handling them incorrectly — especially retrying messages that should never be retried — actively worsens your quality rating and accelerates the problem.

01
Per-second throughput
80 messages/second per phone number. API infrastructure limit. Returns HTTP 429 immediately. Retry with exponential backoff.
HTTP 429
02
Daily messaging tier
1K / 10K / 100K / Unlimited unique business-initiated contacts per 24h. Resets at midnight UTC. Do NOT retry same day.
Error 131048
03
Per-recipient frequency cap
Meta silently blocks marketing messages to recipients who have received too many from any business in the last 24–48h. Never retry.
Error 131049

Rate limit 1: Per-second API throughput

The Cloud API supports 80 messages per second per phone number by default. This is a pure API infrastructure limit — enforced at the millisecond level. Exceeding it returns HTTP 429 immediately with a standard rate limit error. This limit is scalable: contact Meta to increase to 1,000 messages per second for high-volume senders.

The error response when you hit this limit:

HTTP 429 Response
per-second-limit.json
HTTP/1.1 429 Too Many Requests Retry-After: 1 Content-Type: application/json { "error": { "message": "(#613) Calls to this api have exceeded the rate limit.", "type": "OAuthException", "code": 613, "fbtrace_id": "AbCdEfGh..." } } // Retry: YES — use exponential backoff starting at 1 second // The Retry-After header is advisory — respect it but also add jitter

Prevention is better than recovery. At 80 msg/s, sending 10,000 messages takes 125 seconds. For bulk operations, add a 15–20ms delay between sends to stay comfortably under 50–60 msg/s — safely below the limit while maintaining 99%+ delivery success rate.

Rate limit 2: Daily messaging tier limits

This is the limit most people mean when they say "WhatsApp rate limits." The messaging tier controls how many unique customers your phone number can send business-initiated messages to in a rolling 24-hour window. The tier is per phone number, not per account.

Session messages are not tier-limited. The daily messaging tier only counts business-initiated messages — template messages sent to start new conversations or to customers outside the 24-hour service window. When a customer sends you a message first, all replies within the resulting 24-hour service window are session messages — they do NOT count toward your daily tier. You can send unlimited session messages at any tier.
Tier Unique contacts / 24h Starting status Upgrade condition Downgrade condition
Tier 1 1,000 unique contacts All new numbers 7 days consistent usage at 80%+ capacity, GREEN/YELLOW quality rating Quality rating drops to RED
Tier 2 10,000 unique contacts Auto-upgraded 7 days at 80%+ of 10K/day, GREEN/YELLOW quality Quality rating RED → drops to Tier 1
Tier 3 100,000 unique contacts Auto-upgraded 7 days at 80%+ of 100K/day, GREEN/YELLOW quality Quality rating RED → drops to Tier 2
Tier 4 Unlimited Auto-upgraded Achieved after Tier 3 progression Quality rating RED → drops to Tier 3

The error response when you exceed your daily tier:

HTTP 200 with error in body (status: failed)
error-131048.json
{ "messaging_product": "whatsapp", "contacts": [{ "input": "+15550001234", "wa_id": "15550001234" }], "messages": [{ "id": "wamid.HBgL..." }] } // The initial send returns 200. The failure arrives later as a webhook status event: { "statuses": [{ "id": "wamid.HBgL...", "status": "failed", "errors": [{ "code": 131048, "title": "Message failed to send because too many messages were sent from the sender phone number.", "details": "Messages to this phone number are being sent too quickly." }] }] } // CRITICAL: Do NOT retry on 131048. Wait for midnight UTC reset. // Retrying wastes API calls and does not circumvent the tier limit.

Tier progression: how to go from 1K to Unlimited

Meta's tier promotion is automatic — you cannot request it directly. It happens based on three signals measured over a 7-day rolling window:

  1. Volume threshold: You must be consistently reaching 80%+ of your current tier's daily limit. A number sitting at Tier 1 that sends only 200 messages/day never upgrades — even with a perfect quality rating.
  2. Quality rating: Must be GREEN or YELLOW. A RED rating blocks promotion entirely and triggers immediate demotion.
  3. Time: Meta evaluates after 7 consecutive days of meeting both criteria. Promotion is not instant.
Demotion is immediate, promotion is not: A quality rating drop to RED immediately moves you down one tier — you wake up the next day with a lower limit. Recovering back up requires 7 days of clean operation at the new lower tier. This asymmetry means a single bad broadcast campaign can set your tier progression back by weeks. Protect your quality rating as aggressively as you protect your sender reputation.

The quality rating feedback loop

The quality rating (GREEN / YELLOW / RED) is the most important number in your WhatsApp API health. It is computed by Meta over a rolling 7-day window based on signals from message recipients — specifically: blocks, spam reports, and negative feedback relative to your send volume.

GREEN
Healthy — eligible for tier upgrade
Low block and spam-report rate relative to send volume. Recipients are engaging positively — replying, continuing conversations. Eligible for automatic tier upgrade after 7 days at 80%+ capacity. This is the target state for any production sender.
YELLOW
Warning — tier upgrade paused
Moderate block or spam-report rate. You can still send at your current tier limit — no immediate demotion. But tier upgrade is paused. Meta watches for 7 days: if quality improves to GREEN, you remain at current tier. If it degrades to RED, immediate demotion occurs.
RED
Critical — immediate demotion
High block or spam-report rate. Immediate: you're moved down one tier. Sustained RED for 7+ days risks the phone number being flagged or disabled entirely. This is the cascading failure state — a bad campaign creates RED rating → demotion → next campaign has less capacity → more pressure to send at limit → more blocks.

The quality rating is not exposed in the Cloud API directly — you must check it in the Meta Business Manager (WhatsApp Manager → Phone Numbers → Quality Rating column) or subscribe to the phone_number_quality_update webhook field. Subscribe to this field and build alerting so you know immediately when your quality degrades.

Rate limit 3: Per-recipient frequency cap (the one nobody explains)

This is the rate limit that confuses the most developers because it is entirely separate from your account tier, it operates globally across all businesses, and it fails silently with a misleading error message.

Meta's frequency capping limits how many marketing messages a specific WhatsApp user can receive from any business in a defined time window (24–48 hours). This is Meta protecting users from marketing message overload across the entire platform — not just your messages. If a user has received marketing template messages from 5 other businesses today, your perfectly legitimate marketing message to that user may be silently blocked.

The error you receive:

Status webhook — error 131049
frequency-cap-error.json
{ "statuses": [{ "id": "wamid.HBgL...", "status": "failed", "errors": [{ "code": 131049, "title": "This message was not delivered to maintain a healthy ecosystem.", "details": "Unhealthy system activity" }] }] } // This is per-recipient frequency capping — not your account's fault // Affects MARKETING template messages only // UTILITY and AUTHENTICATION templates are NOT frequency-capped per recipient // Do NOT retry — the cap is system-wide, not per sender // Log failed contacts, do not re-attempt for 48h

Key facts about per-recipient frequency capping:

  • Marketing templates only. Utility templates (order confirmations, shipping updates, appointment reminders) and authentication templates (OTPs) are NOT subject to per-recipient frequency capping. If your "marketing" campaign can be legitimately classified as utility, reclassify the template.
  • The cap is global, not per-sender. You have no visibility into how many marketing messages the recipient has received from other businesses. You cannot predict which sends will be capped.
  • Expected failure rate of 10–40% on marketing campaigns to highly active WhatsApp users is normal. This is not a problem with your account — it's the platform protecting users. Budget for it.
  • Never retry 131049 failures. The recipient will be frequency-capped for 24–48 hours. Retrying wastes sends, burns your daily tier quota, and potentially hurts your quality rating.

Complete error code reference

HTTP 429
Per-second throughput limit exceeded
Too many API calls in too short a time. Returned immediately with Retry-After header. Your send rate exceeded 80 msg/s (or your custom limit). This is an infrastructure-level block — the message was never queued.
✓ Retry with exponential backoff + jitter
131048
Daily messaging tier limit exceeded
Your phone number has reached its 24-hour unique contact limit for the current tier (1K, 10K, or 100K). The send appears to succeed initially (returns 200) but fails asynchronously — you receive this code in a status webhook event. The message was not delivered.
⏳ Do not retry today — schedule after midnight UTC reset
131049
Per-recipient frequency cap — "Unhealthy system activity"
The specific recipient has received too many marketing messages from all businesses in the past 24–48 hours. Meta blocked your marketing template delivery to protect this user. Applies only to marketing-category templates. Utility and authentication templates are not affected.
✗ Never retry — recipient is globally capped for 24–48h
131016
Service temporarily unavailable
Transient Meta infrastructure error. Not a rate limit — a server-side failure. The message may or may not have been queued before the error. Safe to retry after 30–60 seconds. Check Meta Status for ongoing incidents.
✓ Retry after 30–60s (max 3 attempts)
131031
Business account locked
Your WhatsApp Business Account has been temporarily locked due to suspicious activity or policy violation. All sends fail immediately. Check Meta Business Manager for violation details. Do not attempt to circumvent — resolve the violation directly with Meta support.
✗ Do not retry — resolve violation in Meta Business Manager

What to never retry — the rule that saves your quality rating

The single most damaging mistake in WhatsApp API error handling: retrying 131048 and 131049 errors. Both of these are asynchronous failures — the API returned 200, you thought the message was sent, then you receive the error later in a status webhook event. Many developers see the failure and immediately retry. This is wrong, and here is why:

  • 131048 (tier limit): The window does not reset until midnight UTC. Retrying means you burn additional messages from your daily quota, fail again, and burn more quota. You also risk sending the same customer a duplicate message when the window resets. Log the failure with the scheduled retry time (midnight UTC) and move on.
  • 131049 (frequency cap): The recipient is capped system-wide, not by you. Retrying does nothing except: (a) consume your daily tier quota, (b) risk generating a delivery-status "failed" signal that could marginally affect your quality rating if interpreted as a spam attempt, (c) potentially annoy the recipient when the cap lifts and they receive duplicates. Log and skip for 48 hours.
The retry decision tree: HTTP 429 → retry with backoff. Error 131048 in status webhook → log, schedule after midnight UTC. Error 131049 in status webhook → log, skip for 48h. Error 131016 → retry once after 30–60s. Error 131031 → stop all sends, fix the account. Any other 5xx → retry up to 3 times with exponential backoff.

Account pausing vs number-level restriction

There are two different account states that look like "my account stopped working" but have different causes and fixes:

Phone number restriction — the specific phone number's messaging is limited or paused. This happens when the quality rating stays RED for 7+ days or when the number receives a specific policy violation. Other numbers in your WABA continue working. Check the number's status in WhatsApp Manager → Phone Numbers. The status field shows "Connected," "Offline," "Flagged," or "Restricted."

WABA suspension — the entire WhatsApp Business Account is suspended. All phone numbers under the WABA stop sending and receiving. This happens from severe policy violations or account-level fraud detection. You receive a account_update webhook event with event: ACCOUNT_RESTRICTION or event: ACCOUNT_VIOLATION.

For agencies: this is why one WABA per client is mandatory. A suspension of one client's WABA has zero effect on other clients' WABAs.

Production retry code: handling all rate limit types correctly

Node.js — production rate-limit-aware send
rateLimitAwareSend.js
const { sendWhatsApp } = require('./whatsapp'); const { scheduleRetry } = require('./scheduler'); const { logFailure } = require('./logger'); // Error codes that should NEVER be retried immediately const NO_RETRY_CODES = new Set([131049, 131031]); // freq cap, account lock const RETRY_NEXT_DAY = new Set([131048]); // tier limit const RETRY_WITH_BACKOFF = new Set([131016]); // transient error async function sleep(ms) { return new Promise(r => setTimeout(r, ms)); } // Handles per-second 429s with exponential backoff async function sendWithThroughputRetry(to, body, attempt = 0) { try { return await sendWhatsApp(to, body); } catch (err) { if (err.status !== 429 || attempt >= 5) throw err; // Exponential backoff with jitter for per-second throughput limit const delay = Math.min( 1000 * 2 ** attempt + Math.random() * 500, 60000 ); console.warn(`429 — waiting ${Math.round(delay)}ms (attempt ${attempt + 1}/5)`); await sleep(delay); return sendWithThroughputRetry(to, body, attempt + 1); } } // Called from your status webhook handler when a message fails asynchronously async function handleFailedStatus(failedStatus) { const errorCode = failedStatus.errors?.[0]?.code; const recipient = failedStatus.recipient_id; const messageId = failedStatus.id; if (NO_RETRY_CODES.has(errorCode)) { // 131049: frequency cap — skip for 48h. 131031: account lock — fix manually. await logFailure({ messageId, recipient, errorCode, action: 'no_retry' }); return; } if (RETRY_NEXT_DAY.has(errorCode)) { // 131048: daily tier limit — schedule retry after midnight UTC const midnightUTC = new Date(); midnightUTC.setUTCHours(0, 5, 0, 0); // 00:05 UTC next day — 5min buffer midnightUTC.setUTCDate(midnightUTC.getUTCDate() + 1); await scheduleRetry({ messageId, recipient, retryAt: midnightUTC }); await logFailure({ messageId, recipient, errorCode, action: 'scheduled_retry', retryAt: midnightUTC }); return; } if (RETRY_WITH_BACKOFF.has(errorCode)) { // 131016: transient error — retry once after 60s await scheduleRetry({ messageId, recipient, retryAt: new Date(Date.now() + 60000) }); return; } // Unknown error code — log and alert for manual review await logFailure({ messageId, recipient, errorCode, action: 'manual_review' }); } // Bulk sender with built-in rate limiting async function bulkSendThrottled(contacts, message, delayMs = 20) { const results = { sent: 0, failed: [] }; for (const contact of contacts) { try { await sendWithThroughputRetry(contact.phone, message); results.sent++; } catch (err) { results.failed.push({ ...contact, error: err.message }); } await sleep(delayMs); // 20ms = ~50 msg/s — safely under 80 msg/s limit } return results; } module.exports = { sendWithThroughputRetry, handleFailedStatus, bulkSendThrottled };

Number warm-up: the right way to build toward Tier 4

A new WhatsApp Business number starts at Tier 1 (1,000 contacts/day). Jumping immediately to large broadcast campaigns is the fastest way to accumulate blocks and spam reports, destroying your quality rating before you've built any trust signal. The correct approach: warm up gradually over 2–4 weeks.

The warm-up strategy that maximizes tier progression speed while protecting quality rating:

  • Week 1: Send to your highest-engagement contacts only — customers who have previously replied to you, purchased recently, or explicitly opted in through a friction-having process. Target 500–800 contacts/day (80% of Tier 1). Monitor quality rating daily.
  • Week 2–3: If quality is GREEN, you should auto-promote to Tier 2. Increase to 7,000–8,000 contacts/day (80% of Tier 2). Continue sending to engaged segments only. Suppress unresponsive contacts who have not engaged in 90+ days.
  • Week 4+: Continue the pattern. Each tier requires 7 days of 80%+ usage with GREEN/YELLOW rating. Total time from Tier 1 to Tier 4: minimum 3–4 weeks of consistent, high-quality volume.
  • Always monitor 131049 failure rates. If you see 131049 (frequency cap) failures exceeding 20–25% of your sends, you're targeting too many high-saturation users. Improve your list quality or reduce frequency before scaling further.
The inbound exception: Inbound messages (customers contacting you first) and session replies do not count toward your daily tier. If your customer service operation is primarily inbound — customers reaching out, your team responding within the 24-hour window — you can handle thousands of conversations daily at Tier 1 with no rate limit concern at all. Rate limits only apply to business-initiated outbound messages. Receive as many inbound messages as you want at SocialHook for a flat $50/month — no rate limit on the receiving side.
FAQ

Common questions

What are the three types of WhatsApp API rate limits?
(1) Per-second throughput: 80 messages/second per phone number — returns HTTP 429 immediately. Retry with exponential backoff. (2) Daily messaging tier: limits unique business-initiated contacts per 24 hours (1K/10K/100K/Unlimited) — returns error 131048 asynchronously via webhook. Do NOT retry until midnight UTC. (3) Per-recipient frequency cap: Meta silently blocks marketing messages to users who've received too many from all businesses in 24–48h — returns error 131049. Never retry.
What does error 131048 mean and should I retry it?
Error 131048 means "Message failed to send because too many messages were sent from the sender phone number" — you've exceeded your daily messaging tier limit. Do not retry same day. The tier window resets at midnight UTC. Schedule a retry for 00:05 UTC the following day. Retrying immediately wastes your remaining quota and does not bypass the limit.
What does error 131049 mean and why is my failure rate high?
Error 131049 ("Unhealthy system activity") is Meta's per-recipient frequency cap. The specific recipient has received too many marketing messages from all businesses in the last 24–48 hours. A 131049 failure rate of 10–40% on marketing campaigns to active WhatsApp users is completely normal — not a problem with your account. This only affects marketing-category templates. Utility and authentication templates are not frequency-capped per-recipient. Never retry 131049 failures.
How do I upgrade my WhatsApp messaging tier?
Tier upgrades are automatic — you cannot request them. You must: (1) consistently reach 80%+ of your current tier's daily limit for 7 consecutive days, and (2) maintain a GREEN or YELLOW quality rating throughout that period. If your quality is GREEN after 7 days at 80%+ capacity, Meta promotes you automatically. YELLOW pauses promotion. RED immediately demotes you one tier. Build tier by focusing on engaged audiences first to protect quality rating.
Do session messages (replies to customer-initiated conversations) count toward the daily tier?
No. The daily messaging tier only counts business-initiated messages — template messages sent to start new conversations or to customers outside their 24-hour service window. When a customer messages you first and you reply within the resulting 24-hour window, those are session messages. They do not count toward your tier limit and have no daily cap at any tier level.
What happens to my quality rating when I get blocks and spam reports?
Blocks and spam reports directly reduce your quality rating over a 7-day rolling window. YELLOW rating pauses tier upgrade eligibility. RED rating immediately demotes you one tier (e.g., Tier 2 → Tier 1) and blocks further upgrades until you return to GREEN. Sustained RED for 7+ days can result in the phone number being flagged or temporarily disabled. Protect your rating by sending only to opted-in contacts who expect your messages, suppressing non-engagers, and classifying messages as utility/authentication instead of marketing where legitimate.
Tutorial
Send Messages via Cloud API
Node.js, Python, and PHP code for every message type — including the bulk sender with rate-limit-compliant delay.
Feature
WhatsApp Inbound Webhooks
No rate limits on receiving. Every inbound message delivered as clean JSON. $50/month flat.
Agency Guide
Managing Multiple Client Numbers
Why separate WABAs per client isolates rate limits and quality ratings across your entire client portfolio.

Rate limits apply to sending.
Receiving is unlimited.

Every inbound message — regardless of volume — gets delivered to your webhook endpoint as clean JSON. No per-second limit, no daily tier, no frequency cap on receiving. Connect your WhatsApp number to SocialHook and handle as many inbound conversations as your customers generate.

Connect WhatsApp free → Read the docs
No credit card required · $50/month after trial · Unlimited inbound volume