LINE Bot Not Responding? The 10 Causes, From the Console Toggle to the Monthly Quota

Every "LINE bot not responding" problem belongs to one of two families: the LINE Platform is not delivering webhook events to your server, or it is delivering them and your reply call is failing. The fix lists are completely different, so decide which family you are in before touching code.

Last verified: 2026-08-20 against the LINE Messaging API reference at developers.line.biz. Error strings quoted below are the literal responses the API returns.

The split is easy to make. Add a log line at the very top of your webhook handler - before signature checks, before parsing - and send your LINE Official Account a message from your phone.

One more thing before you start: LINE does not use numeric error codes the way Meta or Telegram do. A failed call gives you an HTTP status and a JSON body whose message property carries a documented English string such as Invalid reply token. If you already have one of those strings in hand, the LINE error directory maps each one straight to its fix - the rest of this guide covers how the failures present as symptoms.

This is the number one cause of a completely silent LINE bot, and it involves no code at all. LINE only delivers events if three separate things are true in the LINE Developers Console, and missing any one of them produces total silence with no error anywhere.

1. A webhook URL is registered. In the console, open your Messaging API channel, go to the Messaging API tab, and set the URL under Webhook URL. The docs are strict about what qualifies: "The webhook URL must use HTTPS and have an SSL/TLS certificate issued by a certificate authority widely trusted by general web browsers. Self-signed certificates aren't permitted." That last sentence is a real difference from Telegram, which accepts an uploaded self-signed certificate - LINE never does.
2. The Verify button succeeds. After saving the URL, click Verify. The docs say: "If the webhook URL does accept a request, you'll see Success." Verify sends a real request to your endpoint, and your server must answer it with HTTP 200. A handler that rejects the verification request - typically because it fails signature validation on a body with an empty events array, or because a framework returns 404 for the route - fails verification even though the URL is correct.
3. The Use webhook toggle is on. This is the step people miss. Registering and verifying a URL does not enable delivery; the separate Use webhook switch on the same tab must be enabled. A verified URL with the toggle off receives nothing, forever, with no warning.

If registration itself is rejected, the API returns 400 with the body Invalid webhook endpoint URL - a malformed, non-HTTPS, or unreachable-scheme URL. The Invalid webhook endpoint URL page covers every variant. And note what verification does not prove: a syntactically valid HTTPS URL pointing at a dead server is accepted at registration and fails only at delivery time. If the console says everything is green and your server still logs nothing, work through our webhook debugging guide - the causes (TLS chains, firewalls, wrong paths) are shared across every platform.

If users receive some reply - just not the one your code sends - the answer is usually in LINE Official Account Manager, not in your code. Every Messaging API channel is attached to a LINE Official Account, and that account has its own response features that run independently of your webhook.

The default is the trap. Per the docs: "The default setting for Greeting Message and Auto-reply messages is Enabled when the channel is created." So a brand-new channel greets new friends and answers messages with canned text out of the box, and LINE's own recommendation is to turn that off: "we recommend that you set the Greeting messages and Auto-reply messages settings to Disabled, especially if this is the first time for you to create a LINE Bot."

To fix it, open LINE Official Account Manager (there is a direct link from the Messaging API tab in the LINE Developers Console) and check the response settings:

• Auto-reply messages: Disabled. Otherwise users get the canned auto-reply alongside - or instead of - your bot's answer, which reads as the bot being broken.
• Greeting messages: Disabled (or rewritten deliberately). Otherwise new followers get the stock greeting rather than the onboarding your follow event handler sends.
• Chat versus bot handling. The account's response settings also control whether messages are routed to the manual chat inbox for humans. A bot whose messages are landing in a chat inbox nobody watches looks exactly like a bot that stopped responding. If your webhook handler should own the conversation, make sure webhooks are enabled in the response settings and the manual chat feature is not intercepting the messages you expect your code to answer.

The tell-tale symptom that separates this cause from every other one in this guide: the reply arrives instantly and says something you never wrote. A webhook or token problem produces silence; a response-settings conflict produces the wrong voice.

When your handler runs but the reply never lands, check the response body of your reply call. The most common one is:

HTTP/1.1 400 Bad Request

{"message":"Invalid reply token"}

The reference gives exactly two reasons for this string: you "sent a reply message using an expired reply token" or you "sent a reply message using a used reply token." The contract behind it is strict: "Reply tokens can only be used once" and they "must be used within one minute after receiving the webhook. Use beyond one minute isn't guaranteed to work." One webhook event yields one token; that token buys one reply call, which may carry up to five message objects; and the clock starts when the webhook arrives. LINE even warns that the limit "is subject to change without notice" - the docs explicitly tell you not to design around the one-minute figure. Reply as soon as possible, full stop.

Three implementation patterns cause almost every instance:

• Slow work before the reply. A handler that calls a model, a database, and a CRM before replying will blow past the window under load. Send the reply first - or send an immediate acknowledgement - and do the slow work after.
• Two replies to one event. Sending a greeting and then a follow-up as two separate reply calls fails on the second, because the token is spent. Put up to five message objects in a single reply call instead.
• Queued events replayed later. If events sit in a queue for minutes before a worker picks them up, every reply token is dead on arrival. Reply from the ingest path; queue everything else.

Redelivered webhooks are the subtle case: a redelivered event carries the same reply token as the original, usable within one minute of the redelivery - but not if the original was already used, and not once 20 minutes have passed since the event occurred. The full rules live on the Invalid reply token page and the LINE limits page.

When you do miss the window, the fallback is a push message to the event's source. It works - but pushes consume your monthly quota where the reply would have been free, which matters more than it sounds once you read cause 7.

If every API call fails regardless of content, the token is the suspect. The status codes table defines 401 on the Messaging API in one sentence - "Valid channel access token is not specified" - and the body carries the templated string:

{"message":"Authentication failed due to the following reason: XXX"}

where LINE substitutes the specific reason. Whatever the substitution says, the class is constant: the Authorization: Bearer header on this request did not authenticate against this channel.

LINE has several token types, and knowing which one you hold determines the fix:

All of them die - by expiry, by explicit revocation, or by being crowded out during rotation. A 401 in a system that "worked yesterday" almost always means a token aged out or was rotated without a redeploy. The token endpoints report the expiry case explicitly with an OAuth-shaped body: {"error":"invalid_request","error_description":"The access token expired"}.

The other big trap is channel identity. A token authenticates one channel, and user IDs are scoped to that same channel. Pasting a token from a different channel - or from a LINE Login channel under the same provider - produces 401s, or sends that fail in stranger ways. If a token that looks perfectly healthy still fails, confirm it belongs to the channel whose webhook you are receiving. The 401 Authentication failed page walks the full decision tree, including the environment-variable classics: trailing newlines, included quote characters, and the staging token deployed to production.

Every webhook request from the LINE Platform is signed: the x-line-signature header is the Base64 encoding of the HMAC-SHA256 digest of the raw request body, keyed with your channel secret. LINE tells you to verify it rather than filter by IP, because "the IP address of the LINE Platform... isn't disclosed" - and warns that "your bot server may receive HTTP POST requests from sources other than the LINE Platform, and such requests can be malicious."

Signature validation is also where correct bots silently break. The digest is computed over the raw bytes, so anything that touches the body before your check produces a mismatch on every single request:

• JSON middleware that parses and re-serializes. Re-serialized JSON is not byte-identical to what LINE sent. Verify against the raw body, then parse.
• The wrong secret. The signature is keyed with the channel secret, not the channel access token. Swapping them fails every request.
• Charset mutations. A proxy or framework that re-encodes the body breaks the digest even when the JSON looks the same.

Two more delivery rules matter here. First, your server must return HTTP 200 - the docs state "the bot server must return status code 200," and this is also what the console's Verify button checks. Second, LINE "may send an HTTP POST request that doesn't include a webhook event" - a body with an empty events array used as a communication check. A handler that treats an empty events array as an error and returns 4xx fails verification and looks broken to the platform while working fine in your tests.

If you did not return 2xx and have webhook redelivery enabled in the console, LINE retries: redelivered events carry the same webhookEventId (deduplicate on it) and are marked with deliveryContext.isRedelivery, and the docs warn that "the same webhook event may be sent to your bot server more than once" and that ordering is not guaranteed - check the event timestamp. The redelivery attempt count and interval are explicitly "not disclosed... subject to change without notice."

A 403 with this body means your credentials are fine and the gate is entitlement:

{"message":"Access to this API is not available for your account"}

The status codes table describes 403 as "Not authorized to access the resource. Confirm that your account or plan is authorized to access the resource," and the error messages table pins the string: it "appears when calling an API that you do not have permission to use." That makes 403 categorically different from a 401 - no amount of token rotation fixes it, because the problem is what your account is allowed to do, not who it is.

Documented gates worth knowing:

• Narrowcast by attribute requires your LINE Official Account's target reach to be at least 100 people; below that the endpoint refuses.
• IFA-based audiences are "only available to corporate users who have completed certain applications."
• Regional plan differences. LINE Official Account subscription plans differ by country or region, so a capability available to an account in one market may be absent in another. Verify against your region's plan pages rather than assuming parity.

The correct response to a 403 is to check the feature's documented requirements against your account, not to retry. The 403 reference page lists the known gates and where each one is documented.

A bot that worked all month and went silent near the end of it has usually hit this:

{"message":"You have reached your monthly limit."}

Your LINE Official Account has run out of billable sends. The error messages table gives two triggers: you "exceeded the number of free messages" in your subscription plan, or you "exceeded your maximum number of additional messages allowed to be sent" - the paid cap configured in LINE Official Account Manager. The pricing docs confirm the consequence: "when you exceed the limit of messages that can be sent in a month, an error response will be returned and the messages won't be sent."

This is where LINE's reply-versus-push economics bite, and it is the single most important design fact on the platform: only push, multicast, narrowcast, and broadcast count against the quota. Reply messages are not counted at all. Counting is per recipient, not per API call - a push with four message objects to five people counts as five messages - and sends to users who blocked you are not counted. Free allowances depend on the plan and vary by country or region; LINE's documented Japan example is 200 free messages on the free Communication Plan, 5,000 on the Light Plan, and 30,000 on the Standard Plan. The full table, and the narrowcast quota-reservation subtlety that can trigger this error while quota seemingly remains, is on the LINE limits page and the monthly limit error page.

So the fix is twofold. Immediately: raise the paid-message cap or wait for the monthly reset. Structurally: audit every push in your flows and convert any that answer a user's message into replies, because a bot built reply-first may never touch its quota at all.

Note the same 429 status also covers plain rate limiting with a different body - "The API rate limit has been exceeded. Try again later" - enforced per endpoint, per channel (reply and push allow 2,000 requests per second; broadcast and narrowcast just 60 per hour). LINE documents no Retry-After header, so back-off must be self-clocked. Always read the body before deciding which 429 you have.

LINE has no explicit "user blocked you" error anywhere in the Messaging API, which makes this cause uniquely confusing. The block is only observable indirectly, through three signals:

• Profile lookups return 404. A GET /v2/bot/profile/{userId} call answers {"message":"Not found"}. The status codes table enumerates the documented reasons, and the one worth memorizing is the last: "The user blocked the target LINE Official Account after adding it as a friend."
• Push messages still return 200. The docs state the blocked user simply "won't receive the message." Your logs show successful sends; the user sees nothing. Silence plus healthy logs is the classic signature of a blocked user, not a bug. (The one mercy: unreceived messages are not counted against your quota.)
• An unfollow webhook event fired at the moment of the block. This is your only real-time signal - handle it and mark the user inactive in your database.

So a user ID that used to resolve and now returns Not found, with an unfollow event in your history, is a blocked or unfriended user. Stop sending; there is no recovery path through the API. The profile 404 page covers the remaining documented reasons, including the consent case that matters in groups (next section) and cross-channel user IDs - IDs are scoped per channel, so an ID collected by a different channel of the same provider will 404 here even though the human exists.

The status codes table is unusually prescriptive about this one:

{"message":"Request exceeds the max size of 2MB. Make the request smaller than 2MB and try again."}

Two megabytes is the ceiling for the request you POST to the Messaging API, evaluated on the serialized bytes. The important mental model: LINE's message architecture is reference-based, not payload-based. Images, video, and audio are never embedded in the request - message objects carry HTTPS URLs (originalContentUrl, up to 2,000 characters), and LINE's clients fetch the media, with size limits on the hosted files instead (10 MB images, 200 MB video and audio). A correctly built send request is small: up to five message objects with URLs, text under its own character caps, quick replies, structure.

Requests that approach 2 MB almost always mean one of these:

• A data URI or base64 blob pasted where an HTTPS URL belongs
• A huge multicast to array that should have been split (multicast carries up to 500 user IDs per request)
• An audience or rich menu payload that belongs on a different endpoint

Structured caps also fire long before 2 MB for specific objects - a Flex bubble is capped at 30 KB of JSON and a carousel at 50 KB, surfacing as validation errors rather than 413. The 413 page has the full checklist, and the media and per-message ceilings are on the limits page.

A bot that works perfectly in a one-to-one chat and misbehaves in a group is usually meeting documented group rules, not a bug:

• Member profile lookups 404 routinely. In group and multi-person chats you can fetch member profiles only for users who have consented to profile access - by friending the account or agreeing to the consent screen. The status codes table lists "The user hasn't consented to their profile information being obtained" as a documented 404 reason. Treat group-member 404s as expected, and never let one crash the handler mid-loop so the bot stops replying to everyone.
• Reply tokens work the same, but the noise is higher. Group events arrive for every member's message. If your handler does per-message slow work, the one-minute reply window is much easier to blow in a busy group than in a quiet DM.
• Source identifiers change shape. Events from a group carry source.groupId (with userId present only when the sender has consented). Code that assumes source.userId always exists throws on its first group message - and a thrown exception before your 200 response turns one bad event into a delivery failure, then into redeliveries, then into what looks like a bot that randomly double-replies or goes quiet.
• Quota still counts per recipient. A push into a group counts by the people receiving it, so group broadcasts drain a small plan far faster than the same message in 1:1 chats.

The through-line of all four: in groups, defensive handling is the feature. Guard optional fields, expect consent 404s, return 200 no matter what, and log the response bodies - the strings LINE returns are documented and specific, and they are the fastest route back into the error directory.

Run these in sequence. Most silent LINE bots are fixed by step 3.

That last row is the meta-fix. LINE's error bodies name the problem in documented English - Invalid reply token, You have reached your monthly limit., Authentication failed due to the following reason. Code that logs "send failed" throws the answer away. Log the body, then look the string up in the LINE error directory.

Every cause above comes from operating the Messaging API directly: you own the console configuration, the signature validation, the reply-token deadline, the token rotation, and the quota accounting. That is a fine trade for a team with backend capacity to spare - and a poor one when the bot is a support or sales channel for a business, because none of that work is differentiating. The Use webhook toggle, the raw-body signature check, and the one-minute reply window are the same problems for every bot on the platform, and every other chat platform charges a version of the same tax under a different name - as our guides to Telegram bots not responding and chat widgets not showing on a website cover for their transports.

A managed platform handles the transport layer so these failure modes never reach you. With Conferbot's LINE integration, you connect your channel and build the conversation in a visual flow editor - webhook registration, signature validation, reply-versus-push selection, and retry handling are managed for you, and the same flow deploys to WhatsApp, Telegram, and a website widget without rewriting it per platform.

Start free with Conferbot - no credit card needed, so you can have a flow answering on LINE while your hand-rolled webhook is still waiting on a certificate.

If you are debugging a LINE bot today: work the diagnostic table above in order, and keep the error directory open in the next tab. The answer is usually the toggle, the auto-reply setting, or the reply token - in that order.