Every LINE Messaging API limit, in one table

The LINE Messaging API has two limit systems, and confusing them is the classic mistake. The first is engineering: per-endpoint rate limits, applied per channel with a token bucket - most endpoints, including reply and push, allow 2,000 requests per second, but multicast drops to 200 per second, broadcast and narrowcast to 60 per hour, and some rich menu operations to 3 per hour. The second is commercial: your LINE Official Account's subscription plan includes a monthly allowance of free messages, and push, multicast, narrowcast, and broadcast sends all consume it - counted per recipient, not per API call. Reply messages, sent with the single-use replyToken from a webhook event, are explicitly not counted. That reply-first cost model is the thing that surprises teams coming from other platforms: a bot that answers users via push instead of reply works identically in testing and then burns through the plan's free messages in production, ending the month with 429 You have reached your monthly limit. while replies keep flowing for free.

Plan allowances are deliberately not listed as universal numbers here because LINE's own docs say the subscription plan "may vary by country or region"; the documented Japan example runs from 200 free messages on the free plan to 30,000 on the Standard Plan. What is universal: the counting rules, the quota-inspection endpoints, and the errors that fire when you run out.

Everything below is quoted from the Messaging API reference and official docs, with a source link on every row: rate limits, monthly quota mechanics, per-request sending caps, reply token validity, retry-key idempotency, character counting, media specs, quick reply, Flex and template message caps, imagemap, rich menus, webhooks, and audiences. Where a limit fires a specific error, the section intro links the matching page in our LINE error reference.

Rate limits apply "to each API function (endpoint) on a per-channel basis", enforced with a token bucket that refills gradually rather than resetting on the minute - so bursts can pass and sustained overrun drains capacity until requests start failing with 429 The API rate limit has been exceeded. The scope rules are documented: the same URL with a different HTTP method is a different endpoint, request parameters and source IP make no difference, and channels get independent budgets even against the same LINE Official Account. Note the spread below - per-second on the messaging path, but per-minute and per-hour on management, insight, and rich menu endpoints - and that LINE documents no Retry-After header, so backoff must be self-clocked.

Every LINE Official Account can "send a certain number of messages each month for free", with the allowance set by its subscription plan - and the docs are explicit that "the subscription plan may vary by country or region", so treat any specific number as regional. Only proactive sending consumes quota: the pricing page lists push, multicast, broadcast, and narrowcast as counted, and reply messages as not counted. Counting is per recipient - message objects per request don't matter - and messages that can't be received (blocked users, dead IDs) aren't counted. Run out, and sends fail with 429 You have reached your monthly limit.; note narrowcast temporarily reserves quota equal to your full target reach, which can trip that error early.

All five sending endpoints share the same envelope: a messages array of at most 5 message objects, in a request body capped at 2 MB. The differences are in addressing. Push targets one userId, groupId, or roomId; multicast fans out to explicit user IDs; broadcast hits every friend; narrowcast filters by attributes or audiences and carries documented privacy floors that fail either fast with 403 Not enough recipients or late, after a 202, when delivery starts. Invalid recipients produce 400 Failed to send messages; oversized bodies produce 413. Validation-only twins of each endpoint (/validate/push etc.) run the same message-object checks without sending or spending quota.

Reply messages are the free half of LINE's cost model, and the reply token is the gate. Each webhook event that can be responded to carries one token; break any rule below and the reply endpoint returns 400 Invalid reply token. LINE couples the rules with an explicit warning: "the time limit for reply tokens is subject to change without notice" and actual usable duration "may vary due to network delays and other factors" - "don't rely on the time limit for implementation... use reply tokens as soon as possible." A miss isn't fatal: fall back to a push message to the event's source, accepting that the push consumes monthly quota where the reply would have been free.

Push, multicast, narrowcast, and broadcast accept an X-Line-Retry-Key header - "an arbitrarily generated UUID in hexadecimal notation" that you mint yourself ("the retry key isn't generated by LINE"). Retry an ambiguous failure with the same key and LINE either processes the request (if it truly failed) or answers 409 The retry key is already accepted with the original request's ID in x-line-accepted-request-id - never a duplicate delivery. The window is the sharp edge: keys are managed for 24 hours, and LINE warns that reusing a key beyond that "will succeed as a new API request... As a result, duplicate messages will be sent."

Text is capped at 5,000 characters - but "character" means a UTF-16 code unit, so "characters made up of multiple code units (e.g. some Kanji characters, Unicode emojis) are counted as more than one character"; the docs' own example is that the emoji U+1F34E is two characters. LINE emojis add a second trap: their $ placeholders are replaced by alternative text before counting, and "LINE doesn't disclose the alternative text", so a message near the cap "may unintentionally exceed the maximum length and sending the message may fail" - surfacing as 400 The request body has X error(s). A handful of properties (action labels, template text/titles, rich menu names) are counted in grapheme clusters instead.

Media never travels inside the request: message objects carry HTTPS URLs ("Protocol: HTTPS (TLS 1.2 or later)", up to 2,000 characters), LINE's clients fetch the files, and the caps below apply to the hosted files. Getting the transport wrong therefore fails as URL validation (400 with a details array) rather than as an upload error. The reverse direction - downloading what users send you - runs through api-data.line.me and is time-boxed: user-sent content "is automatically deleted after a period of time", after which you get 404 not found, or 410 The content is gone if the user unsent it. Fetch and persist media immediately.

Quick replies ride along on any message type via the optional quickReply property, capped at 13 button objects per message. Two documented behaviors shape UX design: when a request carries several message objects, "the quickReply property of the last message object is displayed" - buttons attached to earlier messages in the batch never render - and buttons using camera, camera roll, or location actions get default icons when imageUrl is omitted. Exceeding the 13-item cap or pointing icons at non-HTTPS URLs fails validation with 400 The request body has X error(s), naming the offending array index in details[].property.

Flex Messages are CSS-flexbox-style layouts defined entirely in JSON, and their caps are JSON-size caps: 30 KB for a bubble, 50 KB for a carousel, and at most 12 bubbles per carousel (all bubbles in one carousel must share the same width setting). Every Flex Message also requires altText - up to 1,500 characters - because notifications and chat lists can't render the layout. These are validation limits, so an oversized container returns 400 The request body has X error(s) pointing into contents, well before the 2 MB transport cap at 413 could matter. Component-level constraints (image URLs, text wrapping, video support by LINE version) live in the Flex container and component references.

Template messages (buttons, confirm, carousel, image carousel) are the pre-Flex structured layouts, and their limits are per-field character caps rather than JSON sizes. The pattern to internalize: text allowances shrink when an image or title is present - a buttons template allows 160 characters of text alone but only 60 alongside an image or title, and carousel columns allow 120 alone versus 60 with image/title. Images across templates are JPEG or PNG, up to 1,024px wide and 10 MB, over HTTPS (TLS 1.2+). Blowing any cap fails as 400 The request body has X error(s) naming the field. Note these template text and title fields are counted in grapheme clusters, per the character-counting rules.

Imagemaps are single images with tappable regions, and they carry the API's most idiosyncratic asset requirement: you don't send one image URL but a base URL, and LINE's clients append a width segment to fetch the right resolution - so your server must serve the image at the documented widths (240, 300, 460, 700, 1040 pixels) under {baseUrl}/{width}. The baseSize.width is always declared as 1040, with height scaled to match. Misconfigured base URLs typically fail at render time on the client, while structural problems - too many actions, a bad URI scheme in an action - fail upfront as 400 The request body has X error(s) (the docs' own example flags areas[0].action.uri with "invalid uri").

Rich menus are created via JSON object plus a separate image upload to api-data.line.me, and both halves have hard specs. The object caps: 20 tappable areas, a 300-character internal name, 14 characters of chat bar text, and a declared size whose width runs 800-2500px with height at least 250px and aspect ratio (width/height) of at least 1.45. The image must match: JPEG or PNG, within those same dimension rules, at most 1 MB - wrong formats fail with 415 Unsupported Media Type. Quantity is capped at 1,000 rich menus per account via the API (delete before creating past the cap), and operations are heavily rate-limited: 100 create/deletes per hour and just 3 batch link/unlink calls per hour - see 429.

The LINE Platform delivers events as HTTPS POSTs to your registered webhook URL, signing every request: x-line-signature is the Base64 encoding of the HMAC-SHA256 digest of the raw request body, keyed with your channel secret - and LINE tells you to verify it rather than filter by IP, because "the IP address of the LINE Platform... isn't disclosed." Your server must return 200 (LINE may also POST an empty events array to confirm communication). Redelivery of failed webhooks exists but is opt-in and deliberately vague: enabled in the console, triggered when you didn't return 2xx, with attempt count and interval "not disclosed... subject to change without notice." Registration failures surface as 400 Invalid webhook endpoint URL; for silent-bot debugging, start with the webhook debugging guide.

Audiences are the recipient lists behind narrowcast, and every stage is capped. A channel can hold 1,000 audiences; an upload audience takes 10,000 user IDs when created by JSON but 1,500,000 when created by file upload (on api-data.line.me); descriptions run to 120 characters. Processing is asynchronous with a hard parallelism ceiling - at most 10 upload/update jobs QUEUED or WORKING per audience at once, beyond which requests fail with 429. Audiences must reach READY status before a narrowcast can reference them (400 Invalid audience group id otherwise), and privacy floors apply at send time: each targeted audience generally needs 50+ recipients - see 403 Not enough recipients.