Every Facebook Messenger Platform limit, in one table

The Messenger Platform's limits come in three species, and confusing them costs debugging time. Policy limits govern when you may send: the 24-hour standard messaging window, the shrinking list of message tags that cross it, and the opt-in mechanisms (one-time notifications, marketing messages) that replace the tags Meta retired in April 2026. Content limits govern what a single message may contain: 2,000 characters of text, 25 MB per attachment, 13 quick replies, 3 buttons, 10 carousel cards. Rate limits govern how fast you may call: a pool of 200 calls per engaged user per rolling 24 hours, 300 sends per second per Page, and a tight 10-calls-per-10-minutes budget on the profile API that trips more deploy scripts than traffic ever does.

Each limit fails with its own error signature. Window violations return code 10 with subcodes like 2018278; oversized media returns 100/2018109; throttling surfaces as 4, 17, 32, 613 or 80006. The tables below name the error each limit fires so you can navigate straight from a log line to the rule behind it, and each row carries the official documentation link, only documented values appear here. The companion catalogue at /errors/messenger explains every code in depth, and the Messenger troubleshooting guide works backwards from symptoms.

Two structural facts shape everything else. First, Messenger enforcement is per-Page: quotas, windows and menus all bind to the Page (and the app connected to it), so multi-Page deployments budget per Page, not per server. Second, identifiers are scoped: recipient PSIDs exist per app-Page pair, which is why they appear in the webhook table below rather than being portable data. Numbers here were verified against Meta's documentation on the date above; Meta adjusts limits with platform announcements, so treat the changelog as part of your dependency list. For building the bot itself, see the Messenger chatbot overview.

The standard messaging window is the platform's core consent rule: once a person interacts with your Page, you have 24 hours to send anything, including promotional content; after it closes, untagged sends fail with error 10/2018278 or 10/2534022. The window re-opens on every qualifying interaction, not just messages, and the list of qualifying actions is longer than most integrations assume. Everything that legitimately reaches a person after the window, one-time notifications, sponsored messages, marketing-message opt-ins, is an explicit consent or paid mechanism, tabulated here with its own caps.

Message tags are the narrow, non-promotional exceptions to the 24-hour window, and 2026 cut the list down hard: Meta documents that as of April 27, 2026, requests carrying CONFIRMED_EVENT_UPDATE, ACCOUNT_UPDATE or POST_PURCHASE_UPDATE receive error code 100. What remains is HUMAN_AGENT for human escalations and the customer-feedback template flow, both on 7-day clocks. Tags never permit promotional content, and per-recipient overuse draws the documented abuse warning 613/2018338 before Page-level restrictions. Tagged sends must set messaging_type to MESSAGE_TAG.

Per-message content limits are enforced at the payload level and fail fast with code 100 variants: oversized files with 100/2018109, unfetchable media with 100/2018008, type mismatches with 100/2018047, and slow video with 100/2018294. The numbers below come from the Send API reference and the quick replies reference; where a cap interacts with another (the 25 MB file cap versus the 75-second video fetch), the tighter constraint wins in practice.

Structured messages have per-component caps that fail as bad parameters (code 100) when exceeded, and silently truncate where rendering rather than validation enforces them, titles especially. The two workhorses are the button template (text plus up to three buttons) and the generic template (cards with image, title, subtitle and buttons, up to ten of them forming a horizontally scrollable carousel). Buttons themselves are shared across templates, quick-reply surfaces and the persistent menu, with a uniform 20-character title cap and 1,000-character postback payload.

Messenger rate limits are per-Page and layered: a rolling 24-hour pool that scales with the audience, per-second ceilings on the Send API, and endpoint-specific budgets. Crossing them returns the throttle family, 4 (app-wide), 17 (user token), 32 (Page), 613 (custom/per-API) and 80006 (Messenger business use case), and Meta's stated best practice is to stop calling, because continued calls extend the block. The X-App-Usage and X-Business-Use-Case-Usage response headers report fill percentages and an estimated_time_to_regain_access, so the limits are observable before they bite.

The Messenger Profile API configures the conversation surface, greeting, ice breakers, get-started button, persistent menu, and it carries the platform's tightest documented budget: 10 calls per 10-minute interval per Page. Deploy scripts that re-set the menu on every restart burn through it and start failing with 613-style throttles; set profile properties on change, not on boot. Profile reads about users have their own failure modes: fields beyond your grant return 2018247, and phone-number-only Messenger accounts return 2018218.

Webhook delivery has documented deadlines on both sides: your endpoint must answer every event with 200 OK within 5 seconds, and Meta's retry ladder is short, immediate retries, a developer alert if delivery still fails after 15 minutes, and a Webhooks Disabled alert with the app unsubscribed from the Page after 1 hour of failures. An unsubscribed bot is the classic silent failure: sends still work, but nothing arrives, the exact scenario walked through in the webhook debugging guide. The identifier rows matter because misread IDs surface later as 100/2018001 on sends.