LINE Messaging API errors, explained one by one

No. LINE returns a plain HTTP status code (400, 401, 403, 404, 409, 410, 413, 415, 429, 500) plus a JSON body with a documented message string such as "Invalid reply token" or "Failed to send messages". Validation problems additionally include a details array where details[].property names the offending JSON field and details[].message describes the fault. There is no separate platform-specific code number to look up.

The reference gives two reasons: the reply token was already used, or it expired. Reply tokens can only be used once and must be used within one minute of receiving the webhook; use beyond one minute isn't guaranteed to work. Sending two reply calls for one event, replaying stored tokens, or replying after slow processing all trigger it. Switch to a push message when you miss the window.

Yes. The pricing documentation lists reply messages under "sending methods that are not counted as message count", while push, multicast, narrowcast, and broadcast messages are counted against the monthly quota of your LINE Official Account's subscription plan. Messages are counted per recipient, and sends to users who blocked you or to non-existent user IDs are not counted.

Four documented causes: you exceeded the per-endpoint rate limit, you exceeded the limit on concurrent audience operations, you used up your plan's free messages, or you hit your configured cap of additional paid messages. The body distinguishes them: "The API rate limit has been exceeded. Try again later." is throughput, while "You have reached your monthly limit." is quota. The fixes are opposite - back off versus upgrade your plan.

The reference sets 2,000 requests per second per channel for the push and reply endpoints (the general "other API endpoints" tier). Multicast is 200 requests per second, broadcast and narrowcast are 60 requests per hour, and issuing short-lived channel access tokens is 370 requests per second. Limits are enforced per channel with a token bucket algorithm, not a fixed reset window.

The status codes table lists four reasons: the user ID doesn't exist, the user hasn't consented to profile access, the user never added your LINE Official Account as a friend, or the user blocked it after adding it. A block therefore surfaces as 404 with body {"message":"Not found"} - there is no explicit "blocked" error, so treat profile 404s on previously working IDs as a likely block.

You generate a UUID yourself and send it in the X-Line-Retry-Key header of a push, multicast, narrowcast, or broadcast request. If LINE already accepted a request with that key, the retry returns 409 Conflict with "The retry key is already accepted" and an x-line-accepted-request-id header instead of sending duplicates. LINE manages keys for 24 hours; after that, the same key is treated as a brand-new request.

The documented rule is one minute from receiving the webhook, and "use beyond one minute isn't guaranteed to work." Tokens in redelivered webhooks can also be used within one minute of the redelivery, unless the original token was already used or 20 minutes have passed since the event occurred. LINE explicitly warns the time limit is subject to change, so reply as soon as possible.

The error messages table says it "appears when calling an API that you do not have permission to use." Several capabilities are gated: narrowcast attribute targeting requires a target reach of at least 100 friends, and Identifiers for Advertisers (IFA) audiences require a completed corporate application. It is an account or plan entitlement problem, not a bug - the same request works on an account that has the capability.

Only if you enable webhook redelivery in the LINE Developers Console (it is off by default). LINE then re-sends webhooks your server didn't answer with a 2xx status, for an undisclosed number of attempts at undisclosed intervals. Redelivered events keep the same webhookEventId and reply token but set deliveryContext.isRedelivery to true, so deduplicate by event ID and expect out-of-order arrival.