LINE error 429: You have reached your monthly limit.

Your LINE Official Account has run out of billable sends for the month. The error messages table gives two triggers: you "exceeded the number of free messages" included in your subscription plan, or you "exceeded your maximum number of additional messages allowed to be sent" - the paid cap you configure 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. Only push, multicast, narrowcast, and broadcast count against the plan; reply messages are not counted at all. Counting is per recipient, not per API call - a push with four message objects to a chat of five people counts as five messages - and sends to users who blocked you or to dead user IDs aren't counted. Free allowances depend on the plan and vary by country or region; as a scale reference, 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, with additional paid messages available only on certain plans. Check your region's plan pages rather than assuming these numbers (details at monthly quota).

One documented subtlety can make this error appear while quota seemingly remains: narrowcast reserves messages up front based on your account's entire target reach, not the actual recipient count. While a narrowcast is delivering, "the number of remaining messages for the current month may be temporarily depleted," and a concurrent send fails with exactly this message. LINE's FAQ covers this case; the mitigation is the narrowcast limit objects (e.g. upToRemainingQuota) or simply not sending during large narrowcast deliveries.

You can see all of this programmatically: GET /v2/bot/message/quota returns your target limit (none or limited with a value), and GET /v2/bot/message/quota/consumption returns messages used this month.

HTTP/1.1 429 Too Many Requests

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

Meter yourself: poll the quota and consumption endpoints daily, alert at 80%, and hard-stop marketing sends before the API does it for you. Architect reply-first - every user-initiated interaction should ride the free replyToken, reserving paid quota for genuinely proactive traffic. Budget campaigns per recipient (friends x messages), and isolate large narrowcasts from transactional pushes in time so reservation-induced depletion can't block operational messages. See monthly quota.