Every WhatsApp Cloud API limit, in one table

Four different things get called a "WhatsApp API limit", and most production incidents come from confusing one with another. The messaging limit (tier) caps how many unique customers you can open business-initiated conversations with in a moving 24 hours, and it is set per business portfolio, not per phone number. Throughput caps how many messages per second a single business phone number can move: 80 mps by default, up to 1,000 mps after an automatic upgrade. API rate limits cap calls per hour per app and WABA, with a separate pair rate limit on how fast you may message one individual. Finally, content caps bound what a single message may contain: characters, buttons, list rows, media bytes. Each fails with a different error code and needs a different fix.

Tier upgrades are mechanical, not discretionary. Verify your business, or send 2,000 delivered high-quality template messages to unique users within a 30-day period, to reach the 2,000 tier; above that, Meta moves you up one tier within 6 hours whenever you have used at least half of your current limit in the past 7 days while keeping quality high. There is nothing to apply for: usage plus quality is the application. If your BSP quotes numbers different from this page, both can be right, because solution providers layer their own queueing, per-account throttles and commercial tiers on top of Meta's platform limits, and some published figures predate Cloud API defaults. The values below are Meta's own, the floor every BSP number sits on.

One date matters more than any number here: on 1 October 2026, free-form service messages inside the 24-hour window become billable per delivered message, turning the window from a formatting rule into a billing boundary. Model the impact with the WhatsApp API cost calculator. Values marked "see docs" are ones Meta describes qualitatively rather than as fixed numbers. Everything here was checked against Meta's documentation on the date shown above; treat the source links as the final word. For the error codes these limits throw when exceeded, see the companion directory at /errors/whatsapp.

The messaging limit is the number of unique WhatsApp user phone numbers you can deliver business-initiated (template) messages to in a moving 24-hour period, counting only messages sent outside an open customer service window. It is calculated at the business portfolio level and shared by every business phone number in the portfolio, so adding a second number adds nothing. When you hit the ceiling, further business-initiated sends fail and WhatsApp Manager shows the number as Restricted until the moving window rolls past enough earlier sends; quality-based throttling surfaces separately as 131048, and per-user marketing caps as 131049. Operational tip: count unique recipients per 24 hours on your own side and cut campaigns off at roughly 90% of the tier, leaving headroom for transactional sends. The full failure catalogue is at /blog/whatsapp-api-error-codes.

Throughput is the speed limit per business phone number, measured in messages per second and inclusive of inbound and outbound messages of all types. Exceed it and sends fail synchronously with 130429 Rate limit hit: the message never enters WhatsApp's pipeline, so there is nothing to wait for and you must re-send. Every Cloud API number starts at up to 80 mps and is upgraded automatically to as much as 1,000 mps once it qualifies; there is no application form. The first upgrade takes the number offline for up to a minute, during which sends return 131057 (maintenance mode). Operational tip: run outbound traffic through a token bucket set slightly below your current tier, and treat 130429 as a signal to drain the queue more slowly rather than retry immediately.

Separate from messaging tiers and throughput, Meta caps how many API requests an app may make against a WABA per hour. These ceilings mostly bite management and read traffic — template CRUD, phone number reads, media fetches — rather than message sends. Exceeding the app-level budget returns error 4; the WABA-level budget returns 80007; both clear on their own, so exponential backoff is the entire fix. The pair rate limit is different in kind: it throttles how fast one business number may message one individual and fails with 131056, typically when a bot loops or an agent pastes a long script as many separate sends. Operational tip: batch consecutive lines addressed to the same user into a single message body — it avoids 131056 and reads better on the customer's screen.

Whether you may send free-form text or must use an approved template depends on the customer service window. It opens when a user messages or calls your business number and lasts 24 hours from their latest message or call, resetting every time. Outside it, a free-form send fails with 131047 Re-engagement message and only templates go through. Conversations that begin from a Click to WhatsApp ad or a Facebook Page call-to-action button open a longer 72-hour free entry point during which every message type is free. The window is also becoming a billing boundary: from 1 October 2026 Meta bills service messages inside it per delivered message — see the October 2026 billing change and model your exposure with the cost calculator. Operational tip: store the timestamp of each inbound message and compute window state locally instead of discovering it via 131047.

Templates are the only message type allowed outside the customer service window, and they carry the most detailed limits: how many a WABA can hold, how long each component can be, how many buttons of each kind are allowed, and how variables may be placed. Getting a limit wrong costs a review cycle — creation is rejected outright (error 2388040 for oversized components), and at send time hydrated text that exceeds the body limit fails with 132005. Meta also paces some marketing templates while it gathers early quality signals, so a healthy template can deliver slowly at first. Operational tip: lint templates before submission with the WhatsApp template checker, and if one is rejected work through the rejection playbook before resubmitting — repeated rejections feed the same quality signals that pause templates.

Free-form messages inside the customer service window have their own ceilings, and they are checked synchronously: an oversized body, a malformed field or too many buttons comes back as 100 Invalid parameter or 131009 immediately, not as a failed status later. Interactive messages are the most constrained, and their numbers differ from template buttons — a reply-button message allows three 20-character buttons while a template allows ten 25-character quick replies — so keep two validation tables. This section also covers the specialised types: contacts, location, reactions, address messages, product messages and typing indicators, each with quirks of its own (a reaction to a message older than 30 days is silently dropped with 131009, for instance). Operational tip: enforce lengths and counts in your own code before calling the API, since synchronous 4xx failures still burn rate-limit budget; the caps here are the ones a WhatsApp chatbot flow builder has to respect at design time.

Each media category has its own size ceiling and accepted MIME types, and the platform checks the real type of the bytes, not the file extension — a renamed file fails anyway. Unsupported types fail with 131051, and uploads Meta cannot process fail with 131053 media upload error; oversized files fail the same way. Uploading media to Meta first and sending by media ID is faster and more reliable at high throughput than sending by link, and uploaded media is stored encrypted for 30 days. Operational tip: validate size and MIME type locally, transcode video to H.264/AAC and OGG audio to mono OPUS before upload, and cache media IDs keyed by content hash so repeated campaigns reuse an upload instead of re-uploading the same asset — remembering the ID itself expires after 30 days.

Each business phone number carries a quality rating based on recent recipient feedback — blocks, reports and the reasons users give when blocking — plus a status that reflects whether it can currently send. Quality is the leading indicator for almost every other limit on this page: it drives template pauses (132015, escalating to 132016 when a template is disabled permanently), quality-based send throttling (131048), messaging-tier downgrades and throughput-upgrade eligibility. The practical consequence of ignoring it is a shrinking ceiling everywhere at once. Operational tip: subscribe to the phone number quality webhooks and alert on any transition out of GREEN, then slow marketing volume immediately — recovery to Medium or High within 7 days keeps your current tier, while a full week at Low costs you one.

Account-level limits govern how many business phone numbers a portfolio can register, how the free test number behaves, and how often a number may be registered or deregistered. They rarely matter day to day but dominate onboarding and migrations: a number cap that has not been raised, a test number quietly used for production, or a retry loop wrapped around a registration script are the classic first-week failures. The registration endpoints are strictly budgeted — burning through attempts returns 133016 and locks the number out for up to 72 hours, and re-registering a freshly deleted number too soon returns 133015. Operational tip: never put /register inside automatic retry logic; run it manually or from a once-only migration script, and confirm success by reading the phone number's status field rather than by retrying.

Inbound messages, delivery statuses, template status changes and account alerts all arrive as webhooks, so your endpoint's behaviour is effectively one of your limits. Meta expects a fast HTTP 200 and retries failures with decreasing frequency for up to 7 days; because retries go to every subscribed app, they routinely produce duplicates. There is no documented hard cap on webhook volume, but a handler that does synchronous work will fall behind at the throughput levels above and make you misread message state — sends look "lost" when it is your receiver that is behind. Operational tip: acknowledge immediately, enqueue, and deduplicate on message ID. If statuses stop arriving entirely, check your subscription and TLS setup before blaming Meta; the catalogue at /blog/whatsapp-api-error-codes distinguishes errors that arrive in webhooks from those returned in the API response.

Since 1 July 2025 Meta charges per delivered template message rather than per conversation, with rates that depend on the template category and the recipient's country calling code. This section summarises the structure and deliberately omits per-country figures — Meta's rate cards are the source of truth. The structural change to plan for is 1 October 2026, when free-form service messages inside the 24-hour window become billable per message; the arithmetic, and the decisions worth making beforehand, are worked through in the October 2026 billing guide, and you can model both eras of your bill with the WhatsApp API cost calculator. Exceeding a "limit" here produces no error code at all — the failure mode is a quietly larger invoice. Operational tip: tag every outbound message with its category and window state in your own logs so you can reconcile Meta's invoice line by line.