LINE error 500: Internal Server Error

The status codes table keeps this one to five words: "Error on the internal server." Something failed on LINE's side while processing an otherwise deliverable request. There is nothing in your payload to fix, no documented sub-codes to branch on, and no promised body shape beyond the standard error JSON - treat any 5xx from api.line.me or api-data.line.me the same way.

The operational question a 500 leaves open is the dangerous part: did the message send before the failure, or not? For reply messages the answer is bounded - the reply token is single-use, so a retry either works or returns Invalid reply token, which itself tells you the original was accepted. For push, multicast, narrowcast, and broadcast, LINE built the answer into the API: send an X-Line-Retry-Key UUID with the original request, retry with the same key on any ambiguous failure, and the platform guarantees you either re-process a genuinely failed request or get a 409 with the accepted request ID instead of a duplicate delivery. This is exactly the scenario the retrying-API-request docs were written for.

Sustained 500s across endpoints usually indicate a platform incident; check the LINE Developers site's news and status information before burning retry budget. Keep the X-Line-Request-Id header from failed responses - it's the identifier LINE support needs.

HTTP/1.1 500 Internal Server Error

{
  "message": "Internal server error"
}

You can't prevent LINE-side failures; you can make them harmless. Send every quota-bearing message with a persisted retry key, run retries through a bounded backoff policy, and alert on 5xx rate rather than individual occurrences. Design webhook processing to tolerate the corresponding LINE-side behavior too - with redelivery enabled, your own outages become recoverable the same way; see the webhook debugging guide.