Messaging platform limits and quotas, one table per platform
How many messages a day, how many per second, how long a message can be, how big a file, how many buttons, how many webhooks - scattered across dozens of documentation pages per platform. Each page below collects them into one table, quotes the documented value, links the source, and shows when it was last verified.
The numbers everyone asks for
Six values cover most planning conversations. Every cell links the platform's full table, where the value sits next to its official source and last-verified date.
| Limit | WhatsApp Cloud API | Telegram Bot API | Discord API |
|---|---|---|---|
| Max message length | 4,096 charactersDetails → | 1-4,096 charactersDetails → | 2,000 charactersDetails → |
| Max file / media upload | 100 MBDetails → | 50 MBDetails → | 10 MiB defaultDetails → |
| Rate limit headline | Up to 80 messages per second per business phone numberDetails → | About 1 message per secondDetails → | 50 requests per second, per botDetails → |
| Broadcast / bulk pacing | 250 unique customers / rolling 24hDetails → | About 30 messages per secondDetails → | Spam-limited; exact rate not publishedDetails → |
| Buttons per message | Up to 3 buttons; title 20 characters; id 256 charactersDetails → | Not documentedDetails → | 5 per row, 5 rowsDetails → |
| Quick replies / command caps | Up to 10 per templateDetails → | At most 100 commandsDetails → | 100 per applicationDetails → |
Headline numbers hide caveats - WhatsApp's broadcast pacing is a tier that grows with volume and quality, Telegram's per-chat and bulk rates are separate ceilings, Discord's upload size rises with server boosts. Click through before you commit one of these to a contract.
Limits that actually shape your architecture
Four kinds of limit appear across every messaging platform, and each one belongs to a different part of your system. Confusing them is how bots end up with retry loops that can never succeed.
Tier limits cap who you can reach: WhatsApp's messaging tiers count unique customers in a rolling 24 hours, starting at 250 for an unverified business. They are a growth constraint, not a code constraint - the fix is verification and quality, and your broadcast product has to expose the ceiling to whoever presses "send to everyone".
Throughput limits cap how fast you send once allowed: WhatsApp's 80 messages per second, Telegram's roughly one per chat per second and 30 per second in bulk. These belong in a send queue with pacing - not in retry logic, because a paced sender rarely trips them at all.
API rate limits cap calls rather than messages: Discord's global 50 requests per second and per-route buckets, WhatsApp's per-hour call quotas. They demand honest 429 handling - read the retry hint, back off, and alert only when the queue keeps growing. The rate limiting guide covers the patterns; the error directory documents each 429 variant.
Content caps - message length, media size, button counts - are validation errors waiting to happen and belong at the edge of your system, checked before anything is queued. They also drive cost: on WhatsApp, whether a message fits one template or two is a billing question, which is what the cost calculator is for.
Related
Frequently asked questions
What counts as a limit here?
Anything the platform will refuse or throttle: messaging tiers and rate limits, message and caption lengths, media sizes, template and button counts, webhook constraints, and the windows that decide whether a message is allowed or billable. Each row quotes the documented value and links the official page it came from, and each platform carries a last-verified date.
Why do the numbers differ from what my provider told me?
Business solution providers sometimes add their own ceilings on top of the platform's, and some values depend on account status - WhatsApp messaging tiers move with verification and quality rating, Discord intents change with bot size. These pages quote the platform's own documented values; if your provider quotes something lower, the lower one applies to you.
How often are these pages checked?
Each page shows the date its values were last verified against the official documentation. Platforms do change limits - WhatsApp's pricing model moved to per-message in July 2025 and further rate changes are scheduled - so treat the verification date as part of the data and check the linked source before relying on a value for a contract or a budget.
What happens when I hit one?
It depends on the kind of limit. Rate limits return a retryable error (HTTP 429, WhatsApp 130429, Telegram 429 with retry_after) and a back-off fixes it. Size and count limits return a validation error that retrying never fixes. Tier limits silently cap delivery until the tier rises. The error code directory at /errors explains which is which for every documented code.
Do limits differ between Cloud API and On-Premises?
The question is now moot: Meta sunset the On-Premises API, and its final supported version expired on 23 October 2025, after which it can no longer send messages at all. Every WhatsApp value on these pages is a Cloud API value. If you are migrating an old On-Premises deployment, expect the Cloud API's own throughput model (80 messages per second by default) rather than the hardware-based scaling you tuned before.
Can I request higher limits?
Rarely by asking, usually by qualifying. WhatsApp messaging tiers and the 1,000-messages-per-second throughput upgrade are granted automatically on volume and quality - verifying your business and keeping quality ratings up is the lever. Telegram sells a higher broadcast ceiling through Paid Broadcasts. Discord's rate limits are fixed, but verification lifts the 100-server cap and an intent review unlocks privileged intents past 100 servers.
Which limits reset daily vs rolling?
Most of the ones that matter are rolling, not calendar-based. WhatsApp messaging tiers count unique customers in a moving 24-hour window, and its Cloud API call limits are per rolling hour. Telegram's retry_after is a rolling cooldown measured in seconds. Discord's REST buckets reset on the X-RateLimit-Reset timestamp, though a few product limits - like 200 application command creates per guild - are genuinely per day.
Do these limits apply if I build on Conferbot?
The platform limits always apply - no vendor can exceed them - but Conferbot handles the pacing for you: broadcasts are queued to your WhatsApp tier, sends are throttled under the per-second ceilings, and retry_after cooldowns are respected automatically. What remains yours to plan around are the product-shaped caps: message length, media size, button counts and template rules.
Let the platform respect the limits for you
Conferbot queues, paces and retries on every channel it connects - you build the conversation, it handles the quotas.